lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <>
Subject Re: The JDK 1.5 Can o' Worms
Date Wed, 25 Jul 2007 23:40:24 GMT

On Jul 25, 2007, at 8:45 AM, Mark Miller wrote:

> After reading last years discussion, I get the feeling that there  
> was more support for moving to 1.5 in Lucene 2.0 than against.  
> However, there did not seem to be enough solid advantages to get  
> past the GCJ issues. The whole argument died on a knifes edge with  
> no change happening. Now, over a year later, the pro arguments have  
> only strengthened, while the cons have weakened -- it's hard to  
> believe that the 1.5 argument won't win this time despite a few  
> holdouts. The arguments for the 1.5 move are certainly not  
> wonderfully compelling (though I do love Map<String,  
> List<String>>), but 1.6 is now the official release and 1.5 has  
> been out long enough to be considered the standard. If you want to  
> go with legacy Java 1.4, I am sure you can deal with legacy Lucene  
> 2.9. Last year, many said the same thing about Lucene 1.9. Now we  
> are talking Lucene 2.9.
> Also, this tid-bit seems to indicate you will be able to use Java  
> 1.5 with GCJ if you really need to.
> January 8, 2007
>    We've merged the |gcj-eclipse| branch to svn trunk. The merge
>    changes gcj to use the Eclipse compiler as a front end, enabling  
> all
>    1.5 language features. This merge also brings in a new,
>    generics-enabled version of Classpath, including some new tools.
>    This new code will appear in GCC 4.3.

There is a big difference between a compiler being able to handle 1.5  
syntax and create correct byte code, and a runtime set of classes.  
GCJ's runtime support is not there yet.

> is probably as valid an option  
> this year as last
> A lot of contrib code is already 1.5, and it seems about time that  
> core made the move as well.
> - Mark
> Grant Ingersoll wrote:
>> On Jul 24, 2007, at 11:39 PM, DM Smith wrote:
>>> 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).
>> I think this just adds to the feeling that we shouldn't have to  
>> wait.  I think it stands to reason that even if GCJ had full 1.5  
>> support, it would take a good amount of time to find its way into  
>> the Linux distributions as the official release, and the same goes  
>> for Lucene 2.4 and 2.9.  Thus, in my mind, you actually have a  
>> good 6 months to a year before Linux users could even consider  
>> updates to the latest anyway.  I know where I work we are usually  
>> manually compiling packages, etc. b/c the official distribution  
>> package is so far behind.
>>> 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.
>> Yep, I understand.  I realize this move has some downsides and I  
>> don't tread here lightly, but I think the downsides are mitigated  
>> by the fact that we can do 2 more releases on 1.4 and you will  
>> have some significant performance improvements in the meantime and  
>> that Lucene is already quite mature such that there is no shame in  
>> being on 2.9 when it comes around.
>>> 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.
>> I am glad you have offered to back port and we probably can take  
>> you up on the offer, but I don't think we can agree to the second  
>> part, simply because of the math.  There are, right now anyway,  
>> 4-5 pretty active committers and only 1 of you.  I don't see how  
>> you could keep up unless you have an automated tool to help or it  
>> was your full time job.
>>> As to what led to this conversation, I bet we can find/invent an  
>>> acceptable substitute for StringBuilder.
>> Actually, my main reason was when I was digging into some methods  
>> that used Collections that weren't documented as to what is in the  
>> Collection.  It is annoying at best to have to open up the source  
>> to go figure out what is in a Collection.
>> Another factor is, when you code all day in 1.5 and all your  
>> macros/live templates are setup for 1.5 constructs and you out of  
>> habit do things in 1.5, I find myself constantly correcting until  
>> my brain finally says "its 1.4, dummy".  I know this is just  
>> looking for excuses, but I think the little things really start to  
>> add up.
>> Mostly, though, I think it gives Lucene Java the feel that we are  
>> behind.  Isn't 1.6 the actual official release at this point?  I'm  
>> not proposing to go there just yet, and I don't think we should.
>> Cheers,
>> Grant
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message