lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <dmsmith...@gmail.com>
Subject Re: The JDK 1.5 Can o' Worms
Date Wed, 25 Jul 2007 03:39:34 GMT

On Jul 24, 2007, at 7:00 PM, Grant Ingersoll wrote:

>  I am going to guess that GCJ will always be significantly behind  
> Sun's Java,

There is an effort to release OpenJDK. That will be Java 1.7 (my  
cynicism is perhaps later). I can't find the web page now, but it  
appears that it will stall gcj development. Gcj is still not yet  
compatible with all of java 1.4.2 (mostly in swing) and even further  
behind 1.5.0.

The problem of going to something that gcj does not support is that  
it is likely that Lucene won't be upgraded in Linux distributions as  
the (L)GPL effectively handcuffs programs that can't provide complete  
open source. This is explicit with GPL v3.

It is hard enough to get it updated as it is. Currently, Lucene 1.9.1  
is the level that is available in JPackage and also in Fedora. (I  
have supplied an rpm spec for 2.0 and 2.2, but it still hasn't gone  
forward).

With regard to the Mac, OSX 10.4 has a penetration of over 80% (I  
forget the exact number), leaving the rest (OSX 10.2 and OSX 10.3)  
with Java 1.4 or lower. Java 1.5 will never be available on earlier  
platforms. OSX 10.4 is just over 2 years old.

So Grant, to your point, the situation with regard to Java runtime  
engines has not changed much in a year. The arguments back then are  
still just as valid today. And I'm still just as opposed to it today  
as I was then. However, I won't reiterate the same points as the  
situation has not significantly changed. We can all go back and dig  
up the old thread.

And in the last year, I have greatly appreciated the performance  
improvements. They have been awesome! Let's keep up the good work.

And my offer to back port still stands. I'd just like to see us not  
fork. Perhaps accept 1.5 patches, but don't apply them until back  
ported.

As to what led to this conversation, I bet we can find/invent an  
acceptable substitute for StringBuilder.

-- DM Smith


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message