When Java 7 was released last week, Lucene and Solr both issued a warning saying that you can't use Java 7 with Lucene or Solr. These are popular text search libraries (and Solr is an app) so this can be pretty severe, and the way the community was informed at first was pretty emotional. See Java 7 paralyses Lucene and Solr for an example of the kind of headline generated.

The actual warnings on the Apache sites are pretty mild and state the problem although not the history of the problem well, and give an expectation of when you'll be able to use Lucene with Java 7.

Some people have written some pretty good responses to the issue, see Don't Use Java 7? Are you kidding me? for one example.

These do a good job of hiding the emotions from the problem; in mailing lists and other forums, the word is that Java 7 is buggy, that Oracle's ignoring the problem (they're not, they are working on the bug and have a fix scheduled) and that Oracle didn't test enough.

I say that's crap. Sure, it'd be nice if Oracle never released a JVM with bugs, but it's silly to blame them for this.

There's enough blame for everyone, for Lucene and Oracle.

Oracle honestly did the right thing, though. They had some optimizations in Java 6 (-XX:+OptimizeStringConcat and -XX:+AggressiveOpts) that could break some code, like all things can. With Java 7, they made the optimizations on by default, starting a month before Java 7's release.

you could say that Oracle should have held off. But why? Eventually you have to release stuff, because otherwise people won't test it, and you'll never know if it works or not. At some point you have to let stuff go to see if it works, and here it didn't. They're working on a fix, which is good.

But what about Lucene's fault here? They screwed up, too. They decided at the last minute to try Java 7 with Lucene and Solr and found out it didn't work. Boo hoo. That's way to late. It's not like Java 7 was sneaking up on anyone, Oracle's been doing webinars and presentations and press releases alot lately to get the word out to whoever's living under a rock and didn't know.

So Lucene should have said hey this thing's coming, maybe we should try it. And when these geniuses did, it was too late to turn back without giving java 7 a huge black eye, which nobody needs. And they weren't testing well even then - they apparently had a bug because their tests relied on the specific order of tests being run, which means they didn't follow the rules about either setting order without fail (which Testng can do and is part of why everyone should use testng instead of junit) or isolating tests completely (which is the best junit can do, because it's still way behind testng in features. But it's the "standard.)

So what did Lucene do? They gave java 7 a black eye anyway, by letting people get upset about it.

They should just shut up.

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

The most important part:

Submit Date 13-MAY-2011

Oracle releases Java 7 with major defects and it is Apache Lucerne and Solr's fault?  Uhhhh...ok.......

eyvalalh adm?ncm

Well said. It's good that they uncovered a bug in .00 release (that's getting fixed soon), but the over-politisized nonsense is silly. Java 7 is a good release with a lot of solid features.

Well said. It's good that they uncovered a bug in .00 release (that's getting fixed soon), but the over-politisized nonsense is silly. Java 7 is a good release with a lot of solid features.

And then there was another company with same story over and over again, Microsoft, they have always the same explanation for it, next time it will be better.

Maybe is there a strategy behind al those problems, divide and conquer.

Yes, Java 7 was a long time in the making, but -as the article mentions- the JVM optimizations in question were turned on a month before release. In other words, there was very little time to test, and the blame for that goes to Oracle, not Apache. That's the opposite of what this post states.

Furthermore, the article cited as an example of "hiding the emotions" does precisely the opposite: it introduces emotions into the debate ("are you kidding me?") when the Apache statement was calm. At no point does the Apache statement call for not using Java 7; it merely states under which circumstances using it with certain Apache software might have disastrous results - which is the responsible thing to do.

Wanting to differentitate between Java 7 and its JVM -as the article cited as evidence does- at a time when only single implementation exists is disingenuous, to say the least.

They should just shut up.

More inflammatory TSS editorial comment desperate to gather posts ... ok. And who are you?

You write: "They had some optimizations in Java 6 (-XX:+OptimizeStringConcat and -XX:+AggressiveOpts) that could break some code, like all things can".

I don't think that's a commonly accepted view about compiler or VM optimizations. They are supposed to preserve the semantics of the code. The reason you can turn them on or off is because the result isn't always better. When Oracle turned them on in Java 7, they surely didn't do this with the intent of adding some excitement to running the VM, but because they believed to have sufficient evidence that they were beneficial.

They turned out to be wrong in that, like anyone can.

The issue at hand is what they did after they were notified that they were wrong.They shipped anyway, and they didn't tell their customers that they know that the VM will once in a while produce wrong results. Some people find this unsurprising, some find it reprehensible.

Here is a slightly sarcastic but very accurate (in my view at least) analysis of this situation from Ted Neward: http://java.dzone.com/news/communities-companies-and-bugs.

I agree that's a much better take on the situation than the one presented above.

I don't think we should get upset about stuff like this. They found a bug. That bug shouldn't have slipped through. We'll fix it (Oracle or some other contributor to OpenJDK) and we'll move forward.

I think all in all this is a sign of a healthy community, and I hope we see more involvement and attention to Java moving forward.

Peace,

Cameron Purdy | Oracle

It would be good to hear from the JDK folks themselves on what really happened here. This was after all, a much anticipated release...

They should have turned them off by default five days before the release, or thirty days, or whatever the time period was.

Recently I became keenly aware of the SSL renegotiation problem. Whoever was managing the JDK at that time decided to stop supporting unsafe renegotiation by default, which broke interoperability of SSL.

I think the person who decides what to turn on by default should be a business person, not a techie.

Heh - this post was good for a belly laugh at least.

Very emotional.  Thank your.

But what about real world?  For enterprise products as a rule of thumb x.0.0 version is for portfolio while x.0.1+ is proven to rely upon.  New shoes honor blisters.

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!

Optimizations can be switched off easily.  But reindexing gigabytes of non-ASCII data is real issue that may prevent you from migrating to Java 7 on a whim.

Unfortunately, many interesting stuff was deffered to JDK 8 and later.  They may as well call it Java 6.5 instead of 7)

To strat with, h-online is non apache site, so what has apache or lucene team to do with the emotions shown in there news article? Secondly, lucene's warning post sound pretty genuine, didnt see anything wrong there. Thirdly, java historically (in its sunny days) was known to always ship stable production builds. These kind of mishaps had been unheard or rare in the past. And finally, I wont be surprise to learn that the autor of this serverside posting is "influenced" by Oracle-java PR campaign. Please some one, what is the background of the author or who is he talking to recently? 

I have never knowingly sent software live with bugs that meant it was unusable for its intended purpose.  That you think this is o.k. is beyond my comprehension.  I don't think that Oracle's actions in this case were acceptable.  And the fact that it was a ".0" release is no excuse either.  Shame on Oracle.  And shame on you for trying to defend this decision.  They know better.  Hopefully you do to.

Take a look here: http://weblogs.java.net/blog/fabriziogiudici/archive/2011/08/02/worried-about-java-7-go-hudson-or-jeskins. One of the bugs was filed as low-priority and hence presumably worth the risk since it happens very infrequently (as the post explains, like almost all software on the planet, the JDK is always released with outstanding minor bugs and feature requests in it's bug tracker). The other two were discovered just a few days before the release. All are assigned high priority now and are getting fixed. The only real question here is whether the most sound judgement call was made under the circumstances.

I do hope the OpenJDK team realizes things have gone too far for them not to present their side of the story themselves soon...

Sorry, my post is obscure.

I try to be strict for own products yet forgiving for others.  I've failed not once.  They (Oracle/Java) failed with 7.  Abuse or defence won't help now.  What done is carved in stone already.

The issue is that we been informed on the matter from other sources not from product owner.  Lucene team is honest and direct.  That'll be great if Oracle do the same and put some warning or humble note about those bugs at major pages.  Where all can see them before downloading J7.  Indeed, there is some info at http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html#knownissues but font is *extremely* small.

Good for you, but that's not the reality for most software beyond perhaps small to mid-sized internal development. Take a look here: http://en.wikipedia.org/wiki/Software_bug. Relevant section:

"It is common practice for software to be released with known bugs that are considered non-critical, that is, that do not affect most users' main experience with the product".

The Wikipedia entry also lists common reasons for minor outstanding bugs in releases. As I said, the real issue here is whether these bugs were really minor. The fact that they have now been converted to major bugs would indicate that the truth is probably somewhere in the middle.

Bugs can (and do) get their priority adjusted as more information becomes available.  See http://robilad.livejournal.com/87097.html 

Command Shift +     is your friend (replace with relevant command to increase font size on your browser of choice...)

A couple of corrections to the above -- the optimization turned on by default was not all of AggressiveOpts, it was a specific optimization for loops.

And the default was not changed a month before the release, it was changed in b139, which was publicly available in April (and all builds subsequent releases).

"They should just shut up." ... right ... so should you ... 

Indeed they should do that

vintage celebs

Indeed they should do that

vintage celebs