Neil McAllister brings the discussion to a new low: https://www.infoworld.com/d/application-development/oracle-javas-worst-enemy-168828
He begins with this remarkable comment - "The Java SE 7 bug itself is the result of a rookie mistake". That's something impressive to state about the engineers who implement the HotSpot VM. But let's move forward. "What Oracle did do in Java SE 7, however, was to enable the faulty optimization by default." - yes, exactly how it should be. New advanced optimizations are often introduced in off-by-default mode, and they are later turned on after some cooking time; and that's usually done only in a feature update, not in the old-n-trusty version like JDK 1.6 now. Then Neil proceeds with the tired, patronizing advise against optimizing things. He ignores that these "golden rules" about premature or unnecessary optimization are only really good for the higher levels of your stack; not for the lower levels like OS kernels, drivers, or core libraries and compilers / language runtimes. The reason we can afford to write simple, elegant Java code that's not twisted by hand-tuning and still run it with decent speed, is that EVERYTHING below our code is heavily optimized. And if it was not: pundits would write blogs stoning Oracle for making Java more bloated and sluggish than those from good ol' Sun. (Sometimes you need new optimizations just to keep the previous performance level, compensating for the weight of new features - in 1.7 I'm sure this applies for example to invokedynamic support.) Major JVM updates MUST be always pushing the envelope of performance, by making new optimizations not only available but also active by default. Non- default opts are only ever exercised by a minuscule number of advanced users, and some things never really mature if you don't take the opportunity of major releases to turn them on by default. There's some risk in doing that; but there's some risk in anything, including every single of the hundreds of new features you get in a major update of the platform - most of these features are NOT full-new APIs that are implemented in isolation and have no risk of causing regression in any preexisting functionality. "And yet it shipped anyway because five days wasn't enough time to fix the problem." - really? Let's say Oracle delayed the release by a few days, maybe a full month if the fix needs to touch a critical piece of the optimizer and would require significant field testing. Then a new release date approaches, and five days before that date, some other group or company tests their very popular product for the first time on JDK 7 and finds another important bug. What do we do, wait forever until no more P1 bugs exist? Even though these bugs will affect a very small number of apps, AND they are trivially avoided by a command-line flag? And the bugs only affect HotSpot Server, which is NOT automatically updated in any platform where Java updates are managed by Oracle? Seriously... But the most annoying thing in the article is the take-home message, that Oracle is "Java's worst enemy". Reality check for Oracle haters: they're better in the QA dept than Sun ever was. People's memory is short, but this is not a problem because the Web remembers; check this for example: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512534 This is a bug from the JDK 6 FCS release (fixed in 6u1). It's the same kind of bug - the JIT compiler silently generates bad code that produces wrong results, the app keeps working happily with risk of corrupting user data and business behavior. Except that it hits much more people than JDK 7's bug, because it's a C1 bug (HotSpot Client). Not to mention API regressions that are often just as bad when they happen in popular APIs like JDBC, Regression, Collections etc. Every single JDK major update's FCS build had its fair share of "the sky is falling" regressions. Nothing to see here, except the fact that Oracle have been very competent moving forward major Java projects - JDK, Glassfish, even JavaFX - so people who have a strong bias against Oracle (or against Java) need to make a storm-in-a-teacup out of the few major mishaps. A+ Osvaldo -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
