Why do I want to run a J2SE 5.0 developer environment when the application that I work on, HealthWatch, deploys to J2SE 1.4.2? Because I want to be able to use development tools and Eclipse Plug-ins that will only run with J2SE 5.0.
I’m going to be giving a lunch and learn on FitNesse next week. I’ve been creating diagrams to understand the HealthWatch code base using UMLGraph. The Eclipse plug-ins, Relo and Mylar, help me to work with large code bases and projects. All of these development tools and plug-ins will only run with the J2SE 5.0 JVM.
Installation and Configuration
Downloading and installing the latest SDK is straightforward and painless. You may want to create a JAVA_HOME environment variable and put %JAVA_HOME%bin at the front of your PATH. I did this because I want our existing command line scripts to run against the J2SE 1.4.2 JVM.
Configuring Eclipse to launch with the J2SE 5.0 JVM is a matter of changing the vm argument in the shortcut to something like:
There is no need to change any of the Eclipse preferences as I still want to compile and run using J2SE 1.4.2. I now have my J2SE 5.0 developer environment. Of course, things are rarely this simple.
On the HealthWatch project we use our HwDatabaseMigrator class to stay agile as we evolve our database schema and testing home state. Some of our migration steps are simple SQL commands. Other steps are more complex and we define the SQL commands for these steps in external files.
After upgrading to J2SE 5.0 andforgetting to adjust my PATH the database migration failed to execute any complex migration step. Adjusting the PATH fixed the database migration.
Now I was curious why HealthWatch code compiled for 1.4 wouldn?t run against the J2SE 5.0 JVM. In retrospect I should have run the HealthWatch unit tests against the J2SE 5.0 JVM. Instead Peter Davison and I debugged the HwDatabaseMigrator class directly and tracked the problem to a change in behaviour in the SqlReader class.
The SqlReader class uses regular expressions to extract SQL statements from an external file and provides a means to iterate over the statements. The code compiles the SQL statement matching pattern using these flags:
~Pattern.MULTILINE | Pattern.CASE_INSENSITIVE
Better flags, given our SQL statement pattern, are:
Pattern.DOTALL | Pattern.CASE_INSENSITIVE
I think the intention was to enable matches that spanned newlines by applying the bitwise not operator to Pattern.MULTILINE. The bitwise not turns on all the other bits which for the J2SE 1.4.2 JVM seems to enable Pattern.DOTALL. Not so for the J2SE 5.0 JVM. By changing the flags to use Pattern.DOTALL we get the same behaviour on both JVMs.
The gotcha when upgrading libraries like the JVM is that things almost always break due to unspecified behaviour changing from one version to the next.