dmsmith555 at gmail
Jul 25, 2007, 4:40 PM
Post #12 of 16
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
> 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.
> http://retroweaver.sourceforge.net/ 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.
>> To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
>> For additional commands, e-mail: java-dev-help [at] lucene
> To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
> For additional commands, e-mail: java-dev-help [at] lucene
To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene