Consequences Of Living On The Edge

We’ve been lucky enough on my current project to move to the latest and greatest Java Software Development Kit (J2SE 1.5). It’s one of those small things that we seem to have a fair (though not total) amount of control over. I think (though I am keen to hear otherwise) that it is the only project in our company who has moved onto this platform in production. I shudder of thinking back to my previous project where we were constrained to Java 1.1.8!

Our team has been developing and testing on the new platform for the last few weeks to ensure that our code remains operational and stable. Here are a few things that we had to do in order to upgrade and you might like to consider if you plan on working with the latest version:

  • Upgrade your IDE – We use the best java IDE as our main development front end. I was previously running an old 3.5 version, and had to upgrade to the newer 4.2 version for support of new language features like Generics. I was glad that we were forced to move only after 4.2 was available because other developers had found many bugs in 4.0.
  • Ensure integration test coverage is high – This project relies on a smaller number of libraries in comparison to my previous project, but our high level of integration tests ensured all of the functions our code exercised worked, or at least we found out what did not. For example, our version of the BeanUtils library didn’t handle some of the things we used it for very well.
  • Test your toolkit – As I mentioned earlier in a previous post, coding style on our project is enforced by a tool called Checkstyle. The latest release does not cope well with the new lexical changes to a Java file so we had to build one based the latest source in their repository (thanks to opensource software!).
  • Exercise new features naturally – Our IDE allows us to configure at what level SDK (1.3, 1.4, 5.0) we would like our syntax to be validated against, and although we were supposed to keep it at 1.4 because the latest version of Checkstyle could still not parse all the new constructs, I accidentally left mine at 5.0. A fellow developer later discovered I had committed some code that exercised Autoboxing without even realising it. Such a nice language improvement (now if only Checkstyle wouldn’t die over the new for-each construct)!

Update Nov 8:

We use YDoc to generate UML diagrams in our javadoc (and to make our Business Analysts happy). YDoc is built with a heavy dependency on JDK1.4.2’s Standard Doclet (that was refactored in the latest JDK). This means that although we can generate standard javadoc, our nice UML diagrams no longer appear. I’ve sent an email to the company (as I have no idea where to find technical support on their site) and now we wait…