Reformulating the Product Delivery Process
Israel Gat, Erik Huddleston and Stephen Chin present how Inovis realized a higher product throughput by using three unconventional Kanban practices and a Lean Release Management tool called APROPOS.
News
Oracle Fixes Eclipse's Java Problem
Posted by Alex Blewitt on Jul 30, 2010
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.
RelatedVendorContent
Comparing WebLogic, WebSphere, Oracle, and Open Source Application Servers
Got fires in production? Find root cause in minutes. FREE Java performance tool
JBoss versus IBM WebSphere: Cost, Performance, Efficiency, Innovation (IBM wins)
Related Sponsor
Dynamic Application Infrastructure delivers the innovation, performance and scalability to build, deploy and manage all types of highly robust applications.
The other JVM
by
Vic _
Posted
Jul 30, 2010 7:56 AM
Oracle deserves no pat on the back
by
Rob Hasselbaum
Posted
Jul 30, 2010 9:19 AM
Some comments
by
Christoph Kutzinski
Posted
Jul 30, 2010 9:26 AM
Re: Some comments
by
James Watson
Posted
Jul 30, 2010 11:59 AM
Oracle should turn this into a positive
by
James Watson
Posted
Jul 30, 2010 11:56 AM
The most apalling article ever posted on infoq?
by
James Richardson
Posted
Aug 2, 2010 5:08 PM
Re: The most apalling article ever posted on infoq?
by
Tester Testersson
Posted
Aug 4, 2010 1:16 AM
-
What about Oracle's other JVM, jRockit, does that work fine?
-
There is plenty of blame to go around here. Clearly, Eclipse has a bug to fix. But your letting Oracle off the hook waaaay too easily here.
"There was no realistic way that the JVM team should have known this would happen."
Totally disagree. Eclipse isn't some random Minesweeper clone languishing in a dark room at Java.net. Eclipse is one of the most important projects in the entire Java ecosystem...if not THE most important. I am troubled by what this episode tells us about Oracle's internal QA process. I would expect a company with their vast resources to have a lab where they run a smoke test of a new release candidate against at least the top 4 or 5 (or 20) downstream products that are based on Java. That's not asking too much. -
nor should the Eclipse team have known that an upcoming rebranding was on the cards.
Erm, of course they should have anticipated that. This is a pretty much unsuprising step after Oracle bought Sun.
After all this whole 'try to recognize the VM type by checking some free text field' seems pretty much like an ugly hack in the Eclipse code base to me.
On the other hand: everyone which does some 'real' work with Eclipse has long ago increased the heap parameters as the default values are never enough for any but the smallest projects.the released build is now 1.6.0_21-b07
D'oh, I don't think that there was ever an official JDK release which changed only in the build number.
IMO Oracle should have made this an 1.6.0_22 - no matter how minor the change is. -
I think this lesson could be used to improve the JVM spec. Some way of querying the VM for what parameter options are supported is clearly needed.
-
On the other hand: everyone which does some 'real' work with Eclipse has long ago increased the heap parameters as the default values are never enough for any but the smallest projects.
I'm actually surprised that a significant number of people allow eclipse to use the default JVM on the system. I've long used the "-vm" parameter to explicitly set the VM that Eclipse uses. -
There is just so much wrong with this article.
1. Crappy IDE does unsupported hoo-ha to twiddle some settings
1a. Somebody changes something somewhere to break unsupported something.
2. Crappy IDE can't change.
3. Somebody fixes something because they can't.
whatever. -
That's the best summary of this incident. Sad but true.
This situation debunks myth of Eclipse being the IDE for complex commercial products. Detecting runtime vendor to change the way how tool works is a flaw of its architecture (and reminds me browser detection hell in some Javascript files).
BTW: Why Eclipse can't have some reasonable memory settings out-of-box? -vm switches are so ugly.
7 comments
Watch Thread Reply