lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: The JDK 1.5 Can o' Worms
Date Wed, 25 Jul 2007 12:45:43 GMT
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. 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:

View raw message