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.
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.
Cheers,
Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
