Don't use Java 7 for anything, unless you have no loops in your program

[gjm11]

"These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs" -- this is very, very broken. They had time to not release a version of Java with known wrong-code and crashing bugs affecting real code.

[tmcw]

For sure. Though, I was impressed that he got through every paragraph without even a hint of the snark that this deserves.

[smcj]

Mitigation would just have required to make an optimizer option non-default, like in 6.

[jbellis]

Workaround: run with -XX:-UseLoopPredicate. (http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/...)

But yeah, pretty bad bug.

[rcmuir]

low priority actually:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134

[firemanx]

This seems fishy to me. I actually got this message as well, and we're evaluating the impact - but this is a tremendously serious and obvious bug to appear in a shipping release of one of the most used softwares on the planet. It just doesn't add up to me.

Does anyone have more details than this message?

[redthrowaway]

Text of Uwe's message for anyone who was as annoyed by that text box as I was:

From: Uwe Schindler Date: Thu, 28 Jul 2011 23:13:36 +0200 Subject: [WARNING] Index corruption and crashes in Apache Lucene Core / Apache Solr with Java 7

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

[VMG]

Can anyone replicate the Stemmer bug (7070134 / first link)?

I just tried it with Arch Linux and it passes on x86, even when passed -XX:+OptimizeStringConcat and -XX:+AggressiveOpts explicitly.

[cageface]

This seems like the sort of thing that should have been caught in automated testing.

[perlgeek]

Also if I were to release a new version of a compiler and VM for a widely used language, I'd try to run some really big projects on top of it and see if they work fine. There's no luck of those in Java world.

[js2]

Disaggregated link - http://mail-archives.apache.org/mod_mbox/www-announce/201107...

[nvarsj]

Smells a bit like FUD to me. We've been using openjdk 7 in production for quite a while now with no problems. This is on million+ LOC applications using various open source software (however, not Lucene or Solr :-)).

I suggest if you're worried, test it and see what happens. This bug sounds like it will hit you immediately if there is a problem.

[speckledjim]

More generally, don't use anything on the day of release... Wait a week or 2 for the bugs to be ironed out.

Surely we've all learnt that by now...

[locopati]

Certainly with Java (speaking from experience going back to 1.0) and most certainly with major language/compiler releases like this one (see 1.5 previously). Java almost always requires a dot-release or two after a major version to iron out the kinks. Which isn't to say don't try it, but try it in development with low expectations. On the other hand, they're usually very quick about turning out the next few dot-releases (I'd wager that it'll be 1.7.3 by September, unless they continue with the silly 1.6.0_xx version format in which case 1.7.0_03).

[koevet]

Great way to boost the confidence of the community in Oracle handling Java...

[jandevos]

It'll be the way they handle this bug that will make/break my confidence. If they fix this quickly enough (even though they have this bug set to a low priority right now) then I won't mind too much.

[anonymous]

Oracle will kill Java

[locopati]

Sun had exactly the same problems with major Java releases (see my comment up-thread).

[speckledjim]

You cannot kill a language, unless everyone stops using it. The chances of that are nil.

But keep on with the hyperbole.

[drivebyacct2]

This blog format is absurd. Narrow column and a fixed width content in a box guaranteed to be smaller than the content. Plus this is effectively blog spam despite being owned by the same place as the original content: http://www.lucidimagination.com/search/document/1a0d3986e48a...

[asg]

Here's the original source for Uwe's email: http://mail-archives.apache.org/mod_mbox/www-announce/201107...

Not sure why a third level reference is being passed around.

[jpr]

Good, loops are just gotos in disguise, and gotos are already banned in Java. This just makes the language more consistent.

[jpr]

Gah, I didn't remember that Java programmers have no sense of humor.