Alan Williamson's Blog

(August 17, 2006) - This week at LinuxWorld Laurie Tolson gave reporters an update on the planned release of Java and its associated tools under an open source license.  By the end of the year, javac and the hot spot compiler will be released.  The precise license details haven't yet been announced yet - that is the part of the equation they are wrestling with the most since there are components within the JDK that aren't theirs to open source.  Politics and licenses aside, let us look at what this means for the humble Java developer, the troops in the trenches churning out code daily.

The first and natural concern is of course the dreading forking.  Forking is when two people make two different changes to the same code base resulting in an incompatibility with one another.  This scenario is Java armageddon - the one we all fear the most.  We have a small taste of this already when writing code for different versions of the JDK, but if you are careful and not always use the cutting edge API's then you're code will still happily run on legacy JVMs.  A good rule of thumb is to write for at least 2 versions behind the current release.  So with 1.6 about to make an appearance, you can safely play with the new tools with the 1.4 API.  Naturally this depends on your own application environment so its not a hard and fast rule by any stretch.

Another area where you may already be maintaining different code bases depending on the production system is with Microsoft J#.   Microsoft only got the rights up to Java 1.1 and if you code your Java application to that 1.1 API, then code will happily run on both the Microsoft .net and Java JVM runtimes.  So writing for different target systems is something developers have been use to for many years now, so should we be worried about the dreaded fork?

The problems faced so far by developers have largely been down to API changes, relying on methods/classes that may or may not exist on the production system.  These are relatively easy to spot with a good development environment.  For example, you can easily tell Eclipse to compile for only 1.4 with it doing all the checking to make sure you haven't lapsed into a 1.5 call.  But forking here could be more sinister than simple API misalignment.  What if you call a method and it does something completely different than you expect?

Sadly this isn't anything new to someone who has been coding Enterprise applications that are designed to run over a wide range of application servers.  Sure there is a standard JavaEE API that exists, but that is no assurance that your application will run fine on all application servers, as the interpretation of some of the API calls is down to the owner of the application server.  Even the standard, relatively small, Servlet API can produce many different results depending on the servlet container.

By forking the underlying JVM we now have a much greater potential for code to either not work or behave differently.  We are putting more responsibility onto the Java developer to either target a given runtime and code exclusively for that, or even worse, forcing them to test with different runtimes across different platforms.  Their job could get a whole lot messier.

We already have different runtimes available to us though, with BEA JRockit and IBM's runtime and these problems don't seem to have raised their ugly head.  The difference here is that these companies had to license the technology from Sun and be made to pass a stringent certification process before launching to the public at large.  In an open source world this certification restriction wouldn't be there.  People could easily hack the JDK to do something different and have no requirements to meet any test criteria.  They could simply use it as is.