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