A lot has been made of the "show stopper bug" in Java SE 7. For the record, here is the original posting from the Apache mailing list, where Uwe Schindler laid it out in full:
Hello Apache Lucene & Apache Solr users,
Hello users of other Java-based Apache projects,
Oracle released Java 7 today. Unfortunately it contains hotspot compiler optimizations, which miscompile some loops. This can affect code of several Apache projects. Sometimes JVMs only crash, but in several cases, results calculated can be incorrect, leading to bugs in applications (see Hotspot bugs 7070134 [1], 7044738 [2], 7068051 [3]).
Apache Lucene Core and Apache Solr are two Apache projects, which are affected by these bugs, namely all versions released until today. Solr users with the default configuration will have Java crashing with SIGSEGV as soon as they start to index documents, as one affected part is the well-known Porter stemmer (see LUCENE-3335 [4]). Other loops in Lucene may be miscompiled, too, leading to index corruption (especially on Lucene trunk with pulsing codec; other loops may be affected, too - LUCENE-3346 [5]).
These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs, affecting also many more applications. In response to our questions, they proposed to include the fixes into service release u2 (eventually into service release u1, see [6]). This means you cannot use Apache Lucene/Solr with Java 7 releases before Update 2! If you do, please don't open bug reports, it is not the committers' fault! At least disable loop optimizations using the -XX:-UseLoopPredicate JVM option to not risk index corruptions.
Please note: Also Java 6 users are affected, if they use one of those JVM options, which are not enabled by default: -XX:+OptimizeStringConcat or -XX:+AggressiveOpts
It is strongly recommended not to use any hotspot optimization switches in any Java version without extensive testing!
In case you upgrade to Java 7, remember that you may have to reindex, as the unicode version shipped with Java 7 changed and tokenization behaves differently (e.g. lowercasing). For more information, read JRE_VERSION_MIGRATION.txt in your distribution package!
On behalf of the Lucene project, Uwe
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7044738
[3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068051
[4] https://issues.apache.org/jira/browse/LUCENE-3335
[5] https://issues.apache.org/jira/browse/LUCENE-3346
[6] http://s.apache.org/StQ
So what's really going on here? Java SE 7's included HotSpot JVM is compiling some loops incorrectly because a flag that enables optimizations during compilation has been turned on by default. That's a nasty bug, for sure, because it means Lucene and Solr users are completely unable to just unpack Java SE 7 and run it. They have to turn off the compiler optimizations before they can use SE 7 at all. But is that really a show stopper? Just about every major version upgrade in history turns something that was off by default in the previous versions on by default in this version. It's a pain, but it's not a show stopper, at least, not now that everyone knows about it. The first people to fire up Lucene on SE 7 sure got a nasty surprise, and corrupted some indexes, though. But now we know, and knowing is half the battle.
Look for a fix in the next update of Java SE 7. It'd be great to compile (pun intended) a list of other affected software packages. I'm sure this can't just screw with Lucene and Solr. But so far, they're the only two I can find complaining on the Internet. Thus, the whole affair makes me think that Apache is being a tad dramatic. But that's to be expected. As are some bugs in an initial release. Java SE 7 is nothing if not brand-spanking new.
At the end of the day, what really happened here is we've seen a symptom of Apache's walking away from the JCP and it's distancing itself from the OpenJDK project. The two should have a group hug and get more work done, but that's not likely to happen, especially with Oracle suing Google over its use of Apache Harmony libraries in Android, and Apache's ire over the slow pace of changes to the JCP itself.