The Benefits Of Open Sourcing Java For Developers

There was an interesting panel discussion at JavaOne today about the open sourcing of Java. The panel was made up of folks developing open source JVMs and a representative from Sun. Compatibility is obviously a common theme to these discussions and there were a number of mentions to just how bug for bug compatible the alternative JVMs are trying to be. It occurs to me though that if all the implementations wind up behaving in precisely the same way, there’s not really any point to having multiple implementations. Yes multiple licenses are nice for particular niches but for the average Java developer, what’s the benefit?

A reporter came up to me after the session (apparently I’d made some good comments) and asked about what benefits I saw. Her first question was about how useful having the source code would be. The trouble is, the source code for the standard Java class library has been available for as long as I can remember and open sourcing Java doesn’t change the legality of copying and pasting code (unless your product is GPL) so there’s no real advantage in source access. There are a few sun.* classes that now have source code available and didn’t previously which can be useful but not overly so.

The other advantage is that was mentioned by the panel is that you can fix bugs for clients *now* instead of having to wait for the next release of Java. Of course, for the average developer this isn’t really an option either because it would involve deploying the fixed JVM to all their customers. It might be feasible for people running controlled servers that just run their apps but it’s unlikely to be practical very often. You could however add a workaround to your application for now and contribute a fix back to the JDK for the future which is likely to happen a fair bit.

One interesting aspect of contributing fixes back is that in a lot of ways, there is an incentive for companies not to contribute the fix back – they now have one less bug than their competitors. If the fix requires significant maintenance contributing it back is a pretty clear win, but many work arounds don’t have any real need for maintenance. They might be in areas of code that are very infrequently changed, they might be modular enough to be quite separate etc.  Ephox products have a lot of work around for bugs in various browsers, JREs and OSs, many of which receive so little attention and maintenance that we can be surprised to find them years later, still working perfectly and still working around an unfixed bug (we do report these to Sun, but few people run into them so they tend to be low priority). The other consideration is that even if future versions of the JRE include the fix, you still can’t remove the work around because the older JVMs are still in use by various clients, so you pay the maintenance price anyway.

There are other business considerations involved with the decision to contribute to the JDK as well – you have to sign the copyright on the code over to Sun which can be a sticking point with a lot of companies. After all, why should Sun get to sell the code that you paid to have developed? (And Sun does still sell the code, they have a bunch of different licenses for the Java code including commercial ones, not just the GPL). You also have to go to the expense of reviewing the various legal agreements for contributors and going through the patch review process etc. It’s not just a simple matter of putting the patch on your blog and it being magically part of the JDK.

It will be really important for the OpenJDK team to work hard to limit these barriers to contribution if they want to attract contributions. I’m certain it’s something that they’re already thinking about, but how it pans out with the lawyers will be interesting to see.

The other potential benefit that an open source JVM may provide is the ability to port it to other OSs and architectures. People are already suggesting that this will mean OS X will always have up to date Java just by recompiling. Unfortunately, it’s just not that simple, you first have to port the JITC to output PPC code instead of x86 which is a huge job, then you have to rewrite the AWT toolkit implementation to work with Quartz. Then you have to write a plugin that works with OS X browsers and deal with all the Cocoa vs Java threading issues. Then you have a working JVM, but still no native L&F, no tie ins to the OS (Apple provide some reasonably simple but very powerful features like being able to put the menubar at the top of the screen and handle dropping files onto the application etc). It’s good that it’s possible to port, but it won’t happen soon and it won’t be easy. Judging by the number of Apple laptops here at JavaOne there may just be enough interest to get it done though. BSD is also a likely candidate for a porting project and that should be a lot simpler.

Beyond that, Java developers aren’t going to see much difference except possibly that they have to stop making assumptions that if it works with Sun’s JRE it will work anywhere. Of course, that’s never been true anyway, particularly from a performance perspective, as people who have brought apps over to OS X have found out. It’s a huge change for the Java community, but one that only a very, very small subset of the community is going to be affected by.