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 PorterStemmer
The 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