The real story behind the Java 7 GA bugs affecting Apache Lucene / Solr | Hacker News Reader

The real story behind the Java 7 GA bugs affecting Apache Lucene / Solr

blog.thetaphi.de

60 pointssshah10 comments

I'm actually flabbergasted that neither the Lucene project nor Oracle tested and found this bug long ago. Java 7 builds have been available for years. Makes me wonder how many developers tried an early Java 7 build, got this error and then didn't report it because they assumed someone else was going to find it and report / fix it.

Update: Earlier report of this bug on June 20th: http://osdir.com/ml/solr-user.lucene.apache.org/2011-06/msg0... Another report of AggressiveOpts crashing PorterStemFilter in Jan: http://elasticsearch-users.115913.n3.nabble.com/Java-6u23-an...

If you see something, say something!

bug/issue reporting is a real pain, and possibly a good business opportunity for someone to fix. But as with many problems, it requires a network effect to have a lasting impact - you'll have a chicken/egg problem from day 1.

There are serious fifteen year old reported errors in java.util.Random which have never been fixed and have finally been declared WONTFIX. Ten years ago I reported that ArrayList's get(), set(), and add() methods were non-inlineable (!) and could be trivially repaired with a single line of code: this was never fixed until recent versions of HotSpot which finally obviated the issue.

We're talking core classes here. So I don't have a lot of faith in the bug reporting process.

The java classes have always had major warts and no one in charge has ever seemed to care.

My personal bugbear: java.lang.Object depends on hundreds of classes including, among other absurdities, the Turkish locale (IIRC). This was about 13 years ago. Of course, the bug was eventually marked WONTFIX.

14 years ago, I adopted Java because it was a beautiful escape from the warty giant that C++ was becoming. Sun sat on it's laurels and, like many others, I moved on to Python.

Now Java is the new C++: unpleasant and to be avoided when possible.

Could you elaborate?

Sorry for the late reply. Not sure which you wanted details on:

- java issues / sun not caring - there are examples above by SeanLuke, gojomo and myself

- java.lang.Object depends on hundreds of classes - violates basic design principles of modularity and avoiding cyclic dependencies

- "Sun sat on it's laurels..." - apart from ignoring existing issues, they also ignored requests for language enhancements (e.g. dynamic language support, covariance, etc) for a long time causing many developers to give up on java for web development and move to python & ruby

I hear you, brother.

I liked how minor-update 6u23 finally 'fixed' a ~10-year old bug in GZIP member handling, in a manner that significantly changed behavior (breaking workarounds for the prior bug), and introduced new bugs in GZIP header handling. (I'd supply the bug number, but their bug database is in another one of its many-minute lulls where login and search are impossible.)

My favorite popular, decade-languishing feature request is this one for verbatim multi-line string literals:

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

This 'syntactic sugar' casually dismissed by Mr. xxxxx@xxxxx could by now have saved thousands (maybe tens of thousands) of hours of developer time, futzing with concatenation and escaping and related bugs.

Another 10-year old issue which has probably cost thousands of developer hours:

String.substring() leaks memory

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

Isn't it funny how the more glacially slow the pace a language takes, the more things break when a tiny little change happens?

Reply on news.ycombinator.com