As reported last week, Oracle reacted swiftly to the issues involving the rebranding of the Java 6u21 update. Since then, Oracle have re-spun the Java install, and for Windows machines, the released build is now 1.6.0_21-b07; since the problem only affected Windows, the Solaris and Linux versions remain at 1.6.0_21-b06.
Oracle should be commended for reacting to, and solving, the problem so quickly. The Eclipse launcher was detects the vendor using a non-supported API, and so Oracle weren't obliged to resolve it; fortunately, they were able to do so in a much faster time than Eclipse was able to respin a new build of Eclipse. Ian Skerrett, marketing director of the Eclipse foundation, summarised it perfectly in a headline “Oracle demonstrates Great Community Support and Fixes Eclipse”
Unfortunately, Ed Burnette's ZDNet blog uses the more confrontational title “Oracle Rebrands Java, breaks Eclipse” which then got picked up by Slashdot and repeated. Ironically, Ed's blog post actually confirms that the fix (released on Monday) does resolve the problem – but due to Twitter's 140-character limit, titles are the only message that come across with the refrences to Ed's post.
There's several morals to this episode, which played out in public faster than it would have before social networks like Twitter came about:
- Even seemingly innocuous changes can have knock-on effects. There was no realistic way that the JVM team should have known this would happen; nor should the Eclipse team have known that an upcoming rebranding was on the cards. However, even small knock-on effects “this can't hurt anyone” can have unforseen consequences. The best advice is to leave point releases for bug fixes only, and leave unnecessary changes to the next version.
- Headlines are repeated more than content. Especially with Twitter, all that can fit in is a headline. And if you have a 'tweet this' button which repeats the headline (as ZDNet does) it can run faster than the content itself. There are some that will not read the content, but just infer from the title what it is about.
- The rebranding will happen anyway in JDK7. Oracle paid a lot of money to acquire the Java rights, and they will be rebranding when JDK7 is released. Consider this a portent.
- This isn't just a problem for Eclipse Helios. The problem goes way back to Eclipse 3.3 when this snooping detection was put in place. Any Eclipse version is susceptible to the issue; the only planned fix is for Eclipse Helios.
- Eclipse isn't just an IDE. It's a platform. So it doesn't just affect the latest-and-greatest JDT (and in any case, developers are fairly quick to respond to updates of their development tools). However, there are many downstream IDEs and applications that are commercially based upon Eclipse; IBM has a whole suite of tools, as does Windriver and even Oracle themselves. Their product roadmaps may be in some cases a whole year behind the Eclipse train itself; and these are the companies that pay for the foundation and committers. Saying “you've got to upgrade to the latest in order to keep running” is tantamount to extortion.
Eclipse has been caught on the back foot with this change. Without Oracle's quick thinking and community spirited action, all downstream adopters of Eclipse (the platform, or the IDE) would have been impacted. It says something about Eclipse's release procedures that in the six years since the yearly simultaneous release train there hasn't been a need to respond to a critical problem; having ironed out all the problems by the fifth or sixth milestone (although it has often been necessary to respin an Eclipse m5a or m5eh sometimes). But the release plan of a 3.6.1 release in September isn't fast enough to fix this particular problem, to say nothing of a 3.5.3 release (at the very least) for Galileo. It's new and uncharted territory for Eclipse to have to respond to a critical bug discovered after go-live; and whilst it wasn't of their making, being able to respond promptly will show that they, too, are responsible software developers. Critics of Microsoft's "Patch Tuesday" say that leaving critical patches until the next scheduled release date is unacceptable; so this is true of Eclipse's release procedures as well.
Oracle have shown how they can be flexible in order to solve the issue in the interim; but the problem has been postponed, not averted. It is up to Eclipse to respond and resolve the problem for the future, not just for those who live on the bleeding edge of the IDE, but for those who build upon the platform after it has left Eclipse's stables.
