Markus is a Developer Advocate at Red Hat and focuses on JBoss Middleware. He is working with Java EE servers from different vendors since more than 14 years and talks about his favorite topics around Java EE on conferences all over the world. He has been a principle consultant and worked with different customers on all kinds of Java EE related applications and solutions. Beside that he has always been a prolific blogger, writer and tech editor for different Java EE related books. He is the Java Community leader of the German DOAG e.V. and it's representative on the iJUG e.V. As a Java Champion and former ACE Director he is well known in the community. Markus is a DZone MVB and is not an employee of DZone and has posted 193 posts at DZone. You can read more from them at their website. View Full User Profile

Don't Use Java 7? Are you kidding me?

  • submit to reddit

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



Published at DZone with permission of Markus Eisele, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Mladen Girazovski replied on Tue, 2011/08/02 - 4:41am

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. 

I think that this is a very bold statement.

How could you know what the avarage use case is and that it is not affected?

What about 3rd Party Libraries or JEE Containers, do they "make big use of optimization"? How do you know?

Can you guarantee that Java 7 can be used in production as is (without applying the workarounds) without any negative effects?

For toy projects Java 7 is atm certainly ok, but for production i'd rather wait until they get the big showstoppers fixed.


Ronald Miura replied on Tue, 2011/08/02 - 5:40am in response to: Mladen Girazovski

@Mladen The problem only affects development, since sysadmins wait at least 2~3 years to update major versions of JDKs in production :)

Markus Eisele replied on Tue, 2011/08/02 - 6:35am

@Mladen Ronald is probably right. And yes, it may be a brave statement, but I believe, that Orcl is not waiting for weeks to get this fixed. So it's also bold to issue a general warning ...

Fab Mars replied on Tue, 2011/08/02 - 6:49am

To me, the fuss about these issues is along the lines of the general trend "I criticize Java although I keep using it everyday". May I remind there were other very serious bugs in the past (several years ago to a few months ago), some worse, and causing much less noise. There were also 26 updates to the JRE6... Do you know how many of the critics around release bug-free software? None. Though the hotspot is much more complex than anything most of us has been working on. Oh sure these issues need to be adressed, and fast, so the industry and the community remain confident in Oracle's abilities to maintain the platform, and are encouraged to adopt Java7 faster. Everyone knows what's left to do then.

Michael Bien replied on Tue, 2011/08/02 - 7:15am

btw all those bugs are already fixed for several days. they are only waiting for the next build.

the whole storry is quite amusing for me since nobody would update to jdk7 in produciton with the first build anyway.

Reza Rahman replied on Tue, 2011/08/02 - 10:53am in response to: Markus Eisele

Thank for posting this. This honestly looks to me like sour grapes from Apache. The gross overreaction is hard to comprehend otherwise.

Mladen Girazovski replied on Tue, 2011/08/02 - 11:37am in response to: Markus Eisele

Alright, i see Ronalds point and it helps me understanding your point.

It's the first Java 7 release , and we won't find more bugs by not using it, and of course, nobody in his right mind would use the first Java 7 release in production.

The Apache guys from Lucene/Solr have the problem that they're SW is failing with Java 7 without the workarounds applied, so their excuse for such a bold warning is that they are directly affected.

Loren Kratzke replied on Tue, 2011/08/02 - 11:43am in response to: Reza Rahman

Sour grapes, perhaps. Personally, I would call it fruit from the fallout. I would certainly take their advice and turn off these optimizations, but then I personally would not consider putting Java7 in prod for quite some time anyway. Cool, yes. But running fresh releases in anything other than a trivial situation is a sure way to get bit in the ass. Best to let the masses shake out the bugs first. Thanks Apache. I am sufficiently spooked beyond my rule of thumb of not running fresh releases in prod. I am still looking forward to playing with the new features in a dev environment though.

Reza Rahman replied on Tue, 2011/08/02 - 12:05pm in response to: Loren Kratzke

I guess everyone has their internal meter on what's right and wrong. A more measured response would have been to advise the community about the bugs and see to it that it gets fixed promtly rather than something that looks like a frivolous call to boycott quite possibly motivated by grievances other than the issue at hand.

I do thorough testing before upgrading anything, let alone something as fundamental as a JVM. It's stability/features that matter, not an abritraliy assigned number. There are alpha/beta tools out there that work with a champ and there are pruduction releases that behave like a chump.

Nicolas Bousquet replied on Tue, 2011/08/02 - 2:59pm

Basically... wait. Java 7 is too youg to be really used and theses bug are a proof of that. Of cours you can play with it, run it for anything not really serious. But even if you just develop with it, you'll want to use this code in production sooner or later. If it is in 6 month or more, you are likely safe, otherwise...

Loren Kratzke replied on Tue, 2011/08/02 - 3:08pm in response to: Reza Rahman

Nice way of putting it. And very true words. I admit that there seemed to be an angry tone to the Apache comments but I also admit that I kind of enjoyed it. I feel like they were jabbing at Oracle more than they were at Java. And until Oracle bought Sun, who actually had the clout and cred to make Oracle flinch?

Not to rant about Oracle, but I must quote James Gosling when he said, "Oracle at the very very highest levels, deeply deeply doesn't give a shit." I think that this whole experience has been sobering for Oracle. Until recently, they thought that community and users that bought their products were the same thing, and that Oracle dictates how people think and act. How wrong they were. Good fun. Thanks for your comments, Reza. You always have good points.

Reza Rahman replied on Tue, 2011/08/02 - 3:49pm in response to: Loren Kratzke

Thanks for the kind words (I mean that very sincerely). I try to be as fair as I can and take things on a case-by-case basis and not prejudge (although who really can do that effectively all the time?).

From personal experience, not everyone at Oracle is a bad guy and not everyone at Apache (or anywhere else for that matter) is a good guy. While I agree with Apache's grievances, I am less than impressed with some of the tacticts they tend to employ. I also have seen very little personally that is clearly ill intentioned in Oracle's handling of Java or the community so far. In fact, I think there is much to give them credit for.

Liam Knox replied on Wed, 2011/08/03 - 4:24am

Depends on the criticality of your software and your job and want to remain in it I guess.  Given Java has had the Decimal format infinite loop bug for about 15 years I would fear it being used in a lot of mission critical domains period.

Personally on production system I would not take a 00 release, its not pragmatic for you, your firm or clients and more will drop out no doubt.   

Reza Rahman replied on Wed, 2011/08/03 - 6:26am in response to: Reza Rahman

BTW, these bugs were just assigned a high priority and should be fixed soon.

Cay Horstmann replied on Thu, 2011/08/04 - 12:19am

I am afraid I don't understand how one can see this as "sour grapes from Apache".

Apache is not a monolithic organization. The Lucene folks and the Harmony folks aren't in cahoots, and they don't have a team of lawyers telling them what to blog about. 

The Lucene folks have a legitimate grievance. They found a critical bug that affects their (much used) project, and they didn't get much traction in reporting it through the normal channels. So they did what people do everywhere these days when their grievances aren't heard--assemble on Tahrir Square, put out blog posts with eye-catching titles, whatever works. And it did work. Oracle now is paying the attention that they should have paid in the first place, and it appears as if a fix will be released "soon".

Hopefully, someone at Oracle will extend a warm thank you and a timeline for a fix. If their lawyers will let them.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.