Mark Stephens has been working with Java and PDF since 1999 and has diversified into HTML5, SVG and JavaFX.

He also enjoys speaking at conferences and has been a Speaker at user groups, Business of Software, Seybold and JavaOne conferences. He has a very dry sense of humor and an MA in Medieval History for which he has not yet found a practical use.

Annoying Java Bugs – who broke right aligned text fields

July 27, 2010 1 min read

Bugs are an unfortunate part of a coder’s life. Working in PDF, which has quite an ‘elastic’ specification and where often real world does not match what is supposedly allowed – Sam yelled at me last week that another PDF file we were looking at was missing supposedly mandatory values – there is lots of scope for coding and logic errors. We have three machines in the office which constantly run regression tests on Windows and Linux, so hopefully we only have to fix a bug once and we can see if a fix breaks other things. So our bugs are a controllable annoyance where we can constantly try to raise our game and improve.

No, the most annoying bugs are the ones we do not write – we can put our hands up to those and can fix them easily…

Last week we had an issue with right aligned text values not appearing correctly. It took some time to hunt this one down as we simply could not reproduce it – until we made sure that we were using the same version of the JVM as our client. It turns out that alignment of right aligned text values was broken in JDK1.6_update 10 and does not appear to have been fixed yet.

The fix is a hack, which adds a spaces to the right of all text values and adds spaces so that all the text values are the same length. Then they align nicely. So tomorrow’s release of JPedal has a boolean flag in it to enable this ‘hack’ to ensure that fields works in all JVMs. Hopefully Sun (or rather Oracle now), will fix it as it is a big deal to anyone writing financial software in Java. It also means that you may need to tie down customers to a certain version of Java to avoid a whole nightmare of issues and work arounds.

Mark Stephens has been working with Java and PDF since 1999 and has diversified into HTML5, SVG and JavaFX.

He also enjoys speaking at conferences and has been a Speaker at user groups, Business of Software, Seybold and JavaOne conferences. He has a very dry sense of humor and an MA in Medieval History for which he has not yet found a practical use.

2 Replies to “Annoying Java Bugs – who broke right aligned text…”

I had a specific problem that existed between about 3 minor revisions in the sun libraries and Struts back in Java 1.4. It would cause a runtime exception to be thrown due to a string hashcode collision. In the source code where the exception was thrown, it actually said “should never happen.” The unfortunate part though was that Sun fixed the problem and removed the thrown exception, but we had to use JRockit, and they had stopped development on one of those 3 minor revisions. I had to put together a thorough analysis of the problem and ship it off to WebLogic and wait for them to finally push out a revision with the updated java classes.

On a side note, I am wondering how you do unit tests on JPedal.

I faced this problem about 4 years ago and came up with a very effective solution that involves generating images and then comparing them to previously approved images. Any pixel that was off by 10% of any R, G or B value would fail the test and output a single image file that showed where on the page the difference occurred. This is more for verifying that the PDFs do not come out incorrectly than anything else, but it’s saved my butt hundreds of times when small changes had bad effects on finished parts of the system.

We test it using a variation on what you mention – we have a LInux server testing all output on about 8,000 files against every change to the repository and add any new files with issues we fix. Any changes break the tests and we investigate.

We also have some specific tests and a lot of tests written using Fest – it allows us to have tests to check all the printing permutations (I think there about 52 at last count).