Don’t Use Java 7, For Anything

By on July 28, 2011

Java 7 GA was released today, but as noted by Uwe Schindler, there are some very frightening bugs in HotSpot Loop optimizations that are enabled by default. In the best case scenario, these bugs cause the JVM to crash. In the worst case scenario, they cause incorrect execution of loops.

Bottom Line: Don’t use Java 7 for anything (unless maybe you know you don’t have any loops in your java code)

UPDATE OCTOBER 28, 2011: As noted on Uwe’s blog, Java 7u1 is documented to include the patches to address these issues.

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

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,


Share on LinkedInShare on FacebookTweet about this on Twitter

Related Posts

Search Hub 2.0 Public Beta

Efficient Field Value Cardinality Stats in Solr 5.2: HyperLogLog

Hey, You Got Your Facets in My Stats! You Got Your Stats In My Facets!!

Stump The Chump: D.C. Winners

What Could Go Wrong? – Stump The Chump In A Rum Bar

Top Posts

Understanding Transaction Logs, Soft Commit and Commit in SolrCloud

Faceted Search with Solr

Nested Queries in Solr

Posted in SearchHub, Technical Article

Your email address will not be published. Required fields are marked *



Norman N.

Meta-Comment: Horizontal scrollbars suck (especially when there’s also a vertical scrollbar). An F for usability.

Andrew Gallagher

Putting a fixed-width, fixed-font quotation in a fixed-width column stylesheet does nothing for the readability.


Finding this one a little hard to believe. Sorry, but anyone familiar with a release process would be suspicious of an announcement like this coming so soon after the release

John C

That’s unbelievable. Well, .NET, Ruby, PHP and Python are always options to use just to name a few. They don’t have critical bugs in their stable versions and you needn’t worry about their licensing either.

Seems to me Java is just going downhill since Oracle took over and I can’t see where it will stop.


really depends on what oracle does. a) they could be poisoning the well; and b) they could just be really bad for java business.

In internet speed/time, java has lived long enough to go to the place where COBOL lives.


Correction: Don’t Use Java For Anything. It is a big bloated piece of garbage that needs to be abandoned.

Benjamin Smith

Sun’s shenanigans with Google over their use of Java is a good indicator of just how secure you are when you build your house on Java’s foundation…

Java 7 is out and about | BoxThoughts

[…] with Java, but alas we are in C# land. Apparently the initial release contains bugs that can “cause incorrect execution of loops“. Yick. I’m sure they will get that all sorted out. I guess all I have to worry about […]


To all the folks who commented on the use of horizontal scrollbars on the “pre” tag: I agree with you completely, and appreciate your feedback. I have forwarded your comments to the people who control the look/feel of this site.

I thought it was clear, but the “Don’t use Java 7” link will take you to a copy of the original email in our archive.


Akintayo: The simplest example (I know of) of the sigsev problem can be found by trying to run the Porter Stemmer code (used in Solr, Eclipse, etc…) as mentioned in java bug#7070134

curl >
java Stemmer /usr/share/dict/words

The “wrong loops” problem is definitely tricker to isolate, but if you look at the mentioned Lucene issues, there are steps to reproduce the problem in Lucene JUnit tests


Anon: While it’s true that “Java7 != HotSpot”, the real issue here is that the optimizations that have these bugs are enabled by default in the Java 7 releases.


So, if the bug is present in JSE6 as well (even if the optimizations are actually disabled by default), why is this being blamed on Oracle?


Bryant: Because they enabled those optimizations by default without community testing. Stupid demonstration apps that only execute loops 5 times are no real testing.

In fact the problems in Java 6 only exist since the time when Oracle aquired Sun (approx 1.6.0_20).


“why is this being blamed on Oracle?”

Because they FAILED to use adequate QA procedures.


Bryant: I don’t think you’ll see anything in this post (or in Uwe’s email) that “blames” Oracle for anything.

In general I think the main concern is that the release would go forward with these buggy optimizations in HotSpot enabled by default — particularly if you look at the dates some of these bugs were posted @


Java 7 also breaks the USPTO’s e-filing system (Entrust)–with a delicious sort of irony–no patent attorneys can log into file patents if they upgrade to JRE 7.


“These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs”

This official statement from Oracle speaks volumes about how their schedule is more important than product quality.

Responsible companies reschedule releases when major bugs arise, no matter the schedule impact. People can keep using the beta build until the bugs are fixed correctly.


A reasonable person NEVER upgrades to the latest version ASAP …they wait for the fallout before making upgrade decisions.


If you don’t blame Oracle, who do you blame? There is no Sun any more. This might still have happened if Sun were running the show, but as there is no longer any Sun, Oracle is the only place to lay blame.

Come on

Come on you negative pos people here. Some people complain about Java. Why are you even here commenting? I’m so sick of negative comments. Java is great and enables cross platform programs and also Android. It’s simple, clear, has threads, high performance and the most pleasant programming language in my opinion.

Java 7 Bug Discovered | Nitin's Blog

[…] from Apache have suggested that the bug may have been present in Java 6 (but has apparently been fixed in the Java 6 u25 service release), but with the optimization flags enabled by default in Java 7, the issue becomes more […]


chimera8: Try JDK 1.6.0_26 with -XX:+AggresiveOpts and run the Porter example application from the bug report. What happens? Yes it crashes you JVM, so which bug is fixed in u25?

» links for 2011-07-29 (Dhananjay Nene)

[…] Lucid Imagination » Don’t Use Java 7, For Anything RT @_navin: WTF?! "Don't use Java 7 for anything, unless you have no loops in your program" (tags: This entry was posted on Saturday, July 30th, 2011 at 7:31 am and is filed under Bookmarks. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site. […]

Fernando Cassia

Bottom line: Java 7 must be so good that the FUD campaign has already started.

Too bad everyone else disagrees with LUCID´s doom and gloom post.Including RedHat…

Java Resurgence

I have ran several Java apps and haven´t found this optimization bug. In fact, I had no crashes at all. Maybe all the apps I´ve tested contain no loops at all? I find that hard to believe.

Seems like a FUD campaign to try to rain on Oracle´s Java 7 launch parade, if you ask me.

Didn´t Lucid take part in the Java7 beta testing process?
Are your concerns present in verifiable OpenJDK7 bug reports?



“t: Because they enabled those optimizations by default without community testing”: Lucene devs did not test their app with the beta versions of Java 7, or (even with the optimization features in java 6 enabled) before. They had maybe one year to test and they did not). Beta versions of Java 7 are available for years, and discussion on these bugs is free on OpenJDK mailings lists, apart from the by database.

Fernando Cassia

Ok, after lots of reading through sky-is-falling posts, I finally gathered:

1. that Oracle learned about it 5 days before GA release, and promised a fix for the first JDK7 security update

2. that Java 6 users are also affected, if they enable

3. That this doom and gloom bug (according to tweets) actually affects very specific conditions, and there is a work-around.

> This means you cannot use 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 options

4. As usual h-online has some of the best, in-depth reporting when it comes to Java, without apocalypse headlines

Java 7 paralyses Lucene and Solr

5. “Don´t use Java 7, for *anything*” seems to me like an extreme headline given the availability of a work-around (point #3 above).



> These problems were detected only 5 days before the
> official Java 7 release, so Oracle had no time to fix
> those bugs,

Hogwash. They had five days to fix it. They could have postponed the release until a fix was available.


Uwe: I tried it with 1.6.0_25. Ran it and it worked. No problems. Tried it about 10 times still works. Can’t seem to get the random factors to align on my box like you can to make it crash. Doesn’t seem reproducible in 1.6.0_25.

Maybe it’s just Java 7 and all the rest of us running apps on Java6 don’t have to freak out?

curl >
java -server -XX:+AggressiveOpts -cp . Stemmer american* british* canadian* english* variant*

> wc -l all_words
706308 total


Chimera8: Maybe it only crashes 64 bit JVMs with SIGSEGV on Java6?

I am in contact with the responsible Oracle developer and he confirms crashes:

“The code in memnode.cpp was there for long time (before 6u26). But before my changes it was guarded by OptimizeStringConcat flag. So if you use -XX:+OptimizeStringConcat or -XX:+AggressiveOpts flags you will hit the same problem (I reproduced it even with 1.6.0_23). The report you pointed misses the rest of hs_err file which should have used flags so it is unclear what flags they used. Vladimir”

come on

Oh come on “Don’t Use Java 7, For Anything” – the 3 bugs are reported for the server VM only.

You’re post is just a “I hate Java” post.

Oracle software standards come to Java | Ronan's Blog

[…] There’s long been and unwritten rule for Oracle Database users: “Never use R1 of the product, always wait for R2″.This was especially true with Database 10g. Now it seems this same issue has come to Java, with Java 7 being released with some glaring issues, Oracle early adopters known this path well. Its a pity, as before now, Java releases tended to be uptaken pretty quickly. Lucid Imagination » Don’t Use Java 7, For Anything […]

Eric S

>> These problems were detected only 5 days before the
>> official Java 7 release, so Oracle had no time to fix
>> those bugs,

> Hogwash. They had five days to fix it. They could have
> postponed the release until a fix was available.

They could have also, at a bare minimum, have simply changed those buggy options not be on by default and proceeded with the release on time.

Java7 | Bonillaware

[…] envuelto en polémica puesto que, cinco días antes del lanzamiento, se descubrió un bug que afectaba a la correcta ejecución de bucles en la JVM HotSpot. Oracle decidió no posponer el lanzamiento oficial y sugirió, como solución temporal, la […]


It’s alarmist overreactions like this that cause soooooooo many problems on the internet, and in the development community. Please refrain from doing things like this in the future. I even suggest deleting this posting.

This bug only occurs under very specific and not too common circumstances. And you can easily be worked around (while waiting for the fix in Java 7 Update 1) via a compiler switch (-XX:-UseLoopPredicate). Readers might want to read for a rational discussion of this MINOR issue.

Fernando Padilla

So.. Is this bug fixed now? Could we get another blog post giving Java7 the “All Clear” at least with regards to known bugs?


FYI: Please note the update.

Last week, Java “7u1” was released, and although the release notes didn’t mention the specific bugs in question, testing suggested that it seemed to resolve the known problems. After Uwe posted a blog on this, the Java 7u1 release notes were updated to reflect that the specific patches had been applied…

(My apologies for not posting this update earlier, but I was on vacation last week)


Just bought a new Dell XPS Ultrabook, all was great until I installed Java 7 Update 4. I’m not a sophisticated user, but none of my sites or apps using Java was working or timed out. So, uninstalled and reinstalled Java 6 Update 32. Works like a dream.


To do that you first need a platform where it works! On my W7 and Fedora machines, Java 7.03 is as dead as a Julius Caesar. No web browser function, no jar file execution, no class file stuff, dead!! Oracle must have a reason for hobbling and flushing the system, not testing the updates and installs, but not sure why. It’s not a good sign when the Java console shows no data, and every app is epic fail except for a few console uses and lame Netbeans training apps. Whazzup Oracle guys. I notice you have been getting notably upset when the community looks under the hood and solves some of your problems, that ain’t right. You seems be up to something.