How bugs in the J2SE api can bite you twice

What do you do with your code when you encounter a bug in a vendor’s implementation of the J2SE API?

Well, you can either work around it or avoid that part of the API by trying a different approach, a third-party solution or rolling your own.

But if you go for the workaround, can you safeguard your code from an eventual bugfix in a future release from that vendor?

Watch a 30 sec demo

Start using Trace Modeler today

Download
30-day fully functional trial
No installation required!

Quit bugging me

Occasionally I’m confronted with bugs in Sun’s J2SE API implementation. Practically all of them are related to the Swing API, but that is to be expected in a graphical application like Trace Modeler.

Well, bugs are a fact of life I guess and the good thing is that suspected bugs can usually be confirmed quite quickly. All thanks to the community, the bug parade and google (quick tip : add site:bugs.sun.com to your google query to confine it to the bug database).

But sometimes I run into bugs that were reported years ago and still haven’t been fixed. So someone out there made an effort to help Sun and improve the situation for all of us by filing a bug report and then nothing was done with it :(

A few weeks ago I got bit by another one. Well, two actually. It cost me the better part of an evening to figure out what was wrong and when I found them in the bug database, they hadn’t even been evaluated! They were reported in 2004-2005 and are really trivial to fix.

If you’re interested, you can read about them in ‘Aging bugs and setting dpi with image io‘.

When to wish a bug won’t get fixed

When you code a workaround to a bug in the J2SE API, that code can become a problem once the bug is fixed. Make sure your application can handle it.

If you don’t and the bug is fixed in release X of the API, your program won’t work with X or any later release. Note that your application can’t verify that the environment it’s running in predates X because you don’t know what X will be.

One way to deal with this is

  1. provide a switch in your application to enable or disable the work-around, enable it for now.
  2. when people start complaining about your application not working properly, refer them to the manual where the switch is explained.

The downside of this approach is that you cannot avoid your users being affected by a bug in the vendor’s implementation. Well, by the bugfix to be precise… So you may want to wish the bug never gets fixed :)

Another possibility is to put an upper limit on the version that can be used with your application (i.e. the most recent one that you know of at build time to have the bug), but that would put a virtual expiration date on your software.

You could also check each new version and create a new release of your software when the bug is fixed. This solution is more time-intensive and will couple your release schedule to the vendor’s. It’s also more demanding on your users who have to stay in sync as well.

If it is possible to determine whether or not the bug is present during the execution of your application (i.e. execute a test case and check if the result is as expected), you could enable or disable the workaround as required. However, this technique isn't always practical.

Thanks a bundle

A way out of this mess is to bundle a JRE with your application and only support that specific version. You know which workarounds are required and your application will run in a known environment.

The way I see it, unless you bundle your application with a specific JRE, any vendor’s bug you work around may bite you a second time.

The downside is, you’ll have to do it for every platform you want to (and can!) support. Bundling a JRE makes the build process more complex, think multiple installers and/or cross-platform installer generators, plus it will increase the size of your deployment package considerably.

For now I’ll stick with the switch-based solution. I’m seriously considering Eclipse RCP for Trace Modeler v2.0, so in the future I might start using the bundled approach ;)

Bugs in vendors’ implementations of the J2SE API undermine the portability of java code, but are a fact of life. It’s important for the community that known bugs are fixed sooner rather than later. The fewer open bugs there are, the less likely it is your users will be affected by one.

So, how do you deal with bugs in a vendor’s J2SE API implementation?

Send in your comments and I'll add them below.

Reader comments

Bram Adams wrote:

Can’t you try the following:

String version=System.getProperties().getProperty(”java.version”);
if(/*good version*/){
  //hurray!
}else{
  //booh…
}

Even better, you could write an aspect for this :-), such that the normal control flow is not disturbed in your base code.

Yanic answered :

That would work if you knew how to distinguish the good from the bad versions. If the API bug hasn’t been fixed at the time you write your code, all versions look equally bad (even with aspect goggles on ;o)

Watch a 30 sec demo

Download

Article copyright © Yanic Inghelbrecht 2007-2008, www.tracemodeler.com | last updated on 06/07/2008