Oracle: Java's worst enemy

The buggy Java SE 7 release is only the latest misstep in a mounting litany of bad behavior

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 Java SE 7 bug itself is the result of a rookie mistake.

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:

  1. The First Rule of Program Optimization: Don't do it.
  2. 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).

1 2 Page
Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies