Oracle shipped Java SE 7 with a serious, showstopping bug, and who was the first to alert the Java community? The Apache Foundation. Oh, the irony.
This is the same Apache Foundation that resigned from the Java Community Process (JCP) executive committee in protest after Oracle repeatedly refused to give it access to the Java Technology Compatibility Kit (TCK).
[ Neil McAllister reveals the most dangerous programming mistakes. | Get software development news and insights from InfoWorld's Developer World newsletter. | And sharpen your Java skills with the JavaWorld Enterprise Java newsletter. ]
It's the same Apache Foundation that developed Harmony, an open source implementation of the Java platform. Google used Harmony to build its Android mobile OS, which is now the subject of a multi-billion-dollar lawsuit from Oracle alleging intellectual property violations. Oracle has subpoenaed documents from the Apache Foundation to help make its case. Nobody is sure what this means for other Harmony users.
It seems as if Oracle would like nothing better than to stomp Apache and its open source Java efforts clean out of existence. And that's a shame, because at this point, Apache is doing a lot more good for the Java community than Oracle is.
Java SE 7's Hotspot JVM: Optimized to death
The Hotspot JVM includes a number of optimization modes that can make your code run faster in some cases. In other cases, those same optimizations can have unintended, negative consequences. In one of the optimization modes in Java SE 7, there is a bug that can cause the JVM to miscalculate loops, which can result in various failures, ranging from segmentation faults to data corruption.
The same problem shows up in Java SE 6 when you enable the same optimizations, so we can't blame Oracle for the code that caused the bug. What Oracle did do in Java SE 7, however, was to enable the faulty optimization by default. That wasn't true for earlier versions.
Anyone who's ever used a compiler knows you don't go enabling aggressive optimizations until you're good and sure your code runs without them -- and sometimes not even then. Computer science theorist Michael A. Jackson offers two succinct rules on the subject:
- The First Rule of Program Optimization: Don't do it.
- The Second Rule of Program Optimization (for experts only!): Don't do it yet.
Even if you're only asking the compiler to find ways to improve performance, rather than tweaking the code yourself, you shouldn't play around with optimization options unless you're sure you know what the compiler is doing. That's why most compiler optimizations default to "off."
But what Oracle did is even worse because these optimizations aren't a feature of the Java source code compiler but of the Hotspot JVM's Just-In-Time (JIT) compiler, which translates Java bytecode into native machine code at runtime.
In other words, the new JVM will break your code on the fly as it executes, even if you didn't try to optimize it at all when you compiled it. Even programs that were compiled with the Java SE 6 compiler and run fine on the Java SE 6 JVM fall prey to the same optimization bugs when run under Java SE 7 (unless you have the foresight to disable the optimizations manually).
Java SE 7: Rushed out the door, bugs and all
At the time the Apache Foundation resigned from the JCP executive committee, Oracle accused the foundation of holding back the progress of Java. In twin statements with eerily coordinated wording, Oracle vice presidents Adam Messinger and Don Deutsch both repeated -- chanted, really -- that Oracle must "move Java forward" and that the Apache Foundation should get in line.
Now we learn that Oracle knew about the Java SE 7 bug fully five days before it shipped the product. And yet it shipped anyway because five days wasn't enough time to fix the problem.
I'm slapping my forehead here. Seriously? The Java community has been waiting five years for Java SE 7, but Oracle was so desperate to "move Java forward" that it couldn't wait any longer, even when it knew it was going to ship a product that contained a major flaw?
I'm reminded of all those years GM shipped shoddy, defective automobiles because nobody was willing to stop the assembly line, even when they saw a problem. This is American innovation at its finest?
Oracle reportedly says it will fix the problem in its next service release -- whenever that might be. Oracle typically issues security bugs on a quarterly basis, but it also issues individual fixes for bugs that are deemed too serious to wait until the next update. It's not clear where this particular bug falls. Wouldn't it be funny if the Java SE 7 release was deemed too important to wait, but fixing its serious bugs wasn't?
A shameful episode for Java
It was only natural that the foundation should discover the bug, as it maintains some of the most important and popular Java tools out there. The projects that noticed the bug were Solr and Lucene, both parts of a high-performance search engine. In addition to those, however, other prominent Java-related Apache projects include Ant, Cocoon, Geronimo, Jakarta, Struts, and Tomcat -- names that should be familiar to any Java developer. In fact, Apache probably does more to benefit Java developers than any single organization outside Oracle itself.
And yet when the Apache Foundation pointed out a glaring flaw in the latest version of Java, it didn't get so much as a thank you, and Oracle didn't so much as issue a mea culpa. So much for community-driven Java.
If I made my living as a Java developer, I would be pounding the walls right now. Oracle should be ashamed of itself. It's almost as if it doesn't care about its customers at all -- ah, but what am I saying?
This article, "Oracle: Java's worst enemy," originally appeared at InfoWorld.com. Read more of Neil McAllister's Fatal Exception blog and follow the latest news in programming at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.