Don't Use Java 7? Are you kidding me?
Java 7 was released yesterday and some guys from the Apache Lucene
& Apache Solr community quickly came up with a couple of issues
which lead them to the point where they are actively rejecting Java 7
and advice anybody else to to likewise. Even a general warning
was issued by Apache Lucene PMC Member Uwe Schindler. But what exactly
is wrong with Java 7 and why shouldn't you use it after waiting nearly
five years for it? Let's look at this.
It's not about Java 7 but about the JVM
First of all, it's not about Java 7 in general but about the HotSpot JVM. The GA release contains three bugs ( 7070134, 7044738 and 7068051) which could affect the users with either JVM crashes or wrong calculations.
Hotspot crashes with sigsegv from PorterStemmerThe first one is about a wrong compiler optimization that changed the loop optimizations. The problem is, that this JVM feature is on by
default, so you have to explicitly disable it by adding -XX:-UseLoopPredicate as an argument. If you are willing to try this by your own, grep the Stemmer.java, a reasonable thick word database (there are some out there) and compile and run it against the text file. What you will see is, that your JVM crashes with a fatal error.
# A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000026536da, pid=5432, t id=6568 # # JRE version: 7.0-b135 # Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b05 mixed mode windows-amd64 compressed oops) # Problematic frame: # J Stemmer.step4()V
It directly happens during code execution, so you will not experience this with JDK 1.6. Especially Lucene has some more recent work going on using a more flexible indexing mechanism based on an algorithm
called PulsingCodec especially this is heavily affected by the bug.
Loop unroll optimization causes incorrect result
This bug refers to the "wrong calculations" part of my introductory section. In very rare situations when OSR (On-Stack Replacement)
compilation is done for nested loops, the control flow breaks and the memory dependencies are not taken into account. That leads to duplicated clones which alter results. (If you like to know more about
the compilation details, have a look at this older overview (PDF)
A minimal workaround is to add -XX:LoopUnrollLimit=1 as an argument.
Clone loop predicate during loop unswitch
This is a bug which relates to an older feature request. It's
introduction finally lead to a new bug. Invalidated jvm stats lead to a jvm crash with loop optimizations again.
Bottom Line
You could be affected. At the moment basically only if you have some parts in your software that make big use of the optimization methods which are broken. But for the average use cases this will not affect you. In general this also will affect Java 6 users but only if they use the optimization options, which are on by default with Java 7 (-XX:+OptimizeStringConcat or -XX:+AggressiveOpts) These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs. At the moment it seems as if they are trying to get this into either the next or the second service release. And last but not least, the source code is open so anyone stubborn enough to dig into it can make a fix.
From http://blog.eisele.net/2011/07/dont-use-java-7-are-you-kidding-me.html
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Tags:
Comments
Mladen Girazovski replied on Tue, 2011/08/02 - 4:41am
I think that this is a very bold statement.
How could you know what the avarage use case is and that it is not affected?
What about 3rd Party Libraries or JEE Containers, do they "make big use of optimization"? How do you know?
Can you guarantee that Java 7 can be used in production as is (without applying the workarounds) without any negative effects?
For toy projects Java 7 is atm certainly ok, but for production i'd rather wait until they get the big showstoppers fixed.
Ronald Miura replied on Tue, 2011/08/02 - 5:40am
in response to:
Mladen Girazovski
Markus Eisele replied on Tue, 2011/08/02 - 6:35am
Fab Mars replied on Tue, 2011/08/02 - 6:49am
Michael Bien replied on Tue, 2011/08/02 - 7:15am
btw all those bugs are already fixed for several days. they are only waiting for the next build.
the whole storry is quite amusing for me since nobody would update to jdk7 in produciton with the first build anyway.Reza Rahman replied on Tue, 2011/08/02 - 10:53am
in response to:
Markus Eisele
Mladen Girazovski replied on Tue, 2011/08/02 - 11:37am
in response to:
Markus Eisele
Alright, i see Ronalds point and it helps me understanding your point.
It's the first Java 7 release , and we won't find more bugs by not using it, and of course, nobody in his right mind would use the first Java 7 release in production.
The Apache guys from Lucene/Solr have the problem that they're SW is failing with Java 7 without the workarounds applied, so their excuse for such a bold warning is that they are directly affected.
Loren Kratzke replied on Tue, 2011/08/02 - 11:43am
in response to:
Reza Rahman
Reza Rahman replied on Tue, 2011/08/02 - 12:05pm
in response to:
Loren Kratzke
I guess everyone has their internal meter on what's right and wrong. A more measured response would have been to advise the community about the bugs and see to it that it gets fixed promtly rather than something that looks like a frivolous call to boycott quite possibly motivated by grievances other than the issue at hand.
I do thorough testing before upgrading anything, let alone something as fundamental as a JVM. It's stability/features that matter, not an abritraliy assigned number. There are alpha/beta tools out there that work with a champ and there are pruduction releases that behave like a chump.
Nicolas Bousquet replied on Tue, 2011/08/02 - 2:59pm
Basically... wait. Java 7 is too youg to be really used and theses bug are a proof of that. Of cours you can play with it, run it for anything not really serious. But even if you just develop with it, you'll want to use this code in production sooner or later. If it is in 6 month or more, you are likely safe, otherwise...
Loren Kratzke replied on Tue, 2011/08/02 - 3:08pm
in response to:
Reza Rahman
Nice way of putting it. And very true words. I admit that there seemed to be an angry tone to the Apache comments but I also admit that I kind of enjoyed it. I feel like they were jabbing at Oracle more than they were at Java. And until Oracle bought Sun, who actually had the clout and cred to make Oracle flinch?
Not to rant about Oracle, but I must quote James Gosling when he said, "Oracle at the very very highest levels, deeply deeply doesn't give a shit." I think that this whole experience has been sobering for Oracle. Until recently, they thought that community and users that bought their products were the same thing, and that Oracle dictates how people think and act. How wrong they were. Good fun. Thanks for your comments, Reza. You always have good points.
Reza Rahman replied on Tue, 2011/08/02 - 3:49pm
in response to:
Loren Kratzke
Thanks for the kind words (I mean that very sincerely). I try to be as fair as I can and take things on a case-by-case basis and not prejudge (although who really can do that effectively all the time?).
From personal experience, not everyone at Oracle is a bad guy and not everyone at Apache (or anywhere else for that matter) is a good guy. While I agree with Apache's grievances, I am less than impressed with some of the tacticts they tend to employ. I also have seen very little personally that is clearly ill intentioned in Oracle's handling of Java or the community so far. In fact, I think there is much to give them credit for.
Liam Knox replied on Wed, 2011/08/03 - 4:24am
Depends on the criticality of your software and your job and want to remain in it I guess. Given Java has had the Decimal format infinite loop bug for about 15 years I would fear it being used in a lot of mission critical domains period.
Personally on production system I would not take a 00 release, its not pragmatic for you, your firm or clients and more will drop out no doubt.
Reza Rahman replied on Wed, 2011/08/03 - 6:26am
in response to:
Reza Rahman
Cay Horstmann replied on Thu, 2011/08/04 - 12:19am
I am afraid I don't understand how one can see this as "sour grapes from Apache".
Apache is not a monolithic organization. The Lucene folks and the Harmony folks aren't in cahoots, and they don't have a team of lawyers telling them what to blog about.
The Lucene folks have a legitimate grievance. They found a critical bug that affects their (much used) project, and they didn't get much traction in reporting it through the normal channels. So they did what people do everywhere these days when their grievances aren't heard--assemble on Tahrir Square, put out blog posts with eye-catching titles, whatever works. And it did work. Oracle now is paying the attention that they should have paid in the first place, and it appears as if a fix will be released "soon".
Hopefully, someone at Oracle will extend a warm thank you and a timeline for a fix. If their lawyers will let them.