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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
