
Don't use Java 7 for anything, unless you have no loops in your program - suprgeek
http://www.lucidimagination.com/blog/2011/07/28/dont-use-java-7-for-anything/
======
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.

------
jbellis
Workaround: run with -XX:-UseLoopPredicate.
([http://mail.openjdk.java.net/pipermail/hotspot-compiler-
dev/...](http://mail.openjdk.java.net/pipermail/hotspot-compiler-
dev/2011-July/005971.html))

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...](http://mail-archives.apache.org/mod_mbox/www-
announce/201107.mbox/%3C001601cc4d6b$37618880$a6249980$@apache.org%3E)

------
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).

------
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...](http://www.lucidimagination.com/search/document/1a0d3986e48a9348/warning_index_corruption_and_crashes_in_apache_lucene_core_apache_solr_with_java_7)

~~~
asg
Here's the original source for Uwe's email: [http://mail-
archives.apache.org/mod_mbox/www-announce/201107...](http://mail-
archives.apache.org/mod_mbox/www-
announce/201107.mbox/%3C001601cc4d6b$37618880$a6249980$@apache.org%3E)

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

~~~
drivebyacct2
Oh great, so I was still using some gated linked. Thanks for the original,
it's even easier on the eyes than my source anyway.

------
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.

~~~
Confusion
Jokes that many members could come up with have no place on Hacker News.
That's the road to devolving into a community where everyone tries to out-joke
each other and the actual insightful comments get buried under the jokes. Just
grin at the thought and enjoy the happiness, but don't post it. It's not that
it's not funny; it's just that it is too easy a comment.

