lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Engels" <>
Subject RE: Lucene and Java 1.5
Date Tue, 30 May 2006 16:07:22 GMT
If you can control them to run 1.4, you can probably control them to run

Any performance gains offered by 2.1 would pale in comparison to your user's
upgrading their machines. If not, they stick with 2.0 based Lucene, and run
it under 1.4 

Why don't your users run MS-DOS? It would be the fastest on their machines?
They don't because it is impractical. It is also impractical to continue to
develop software against 1.4 when Sun does not actively support it (they
don't fix bugs in it), so the code in Lucene becomes "unclean" when we need
to add "fixes" for JDK issues which are already fixed in a later JVM.

-----Original Message-----
From: DM Smith [] 
Sent: Tuesday, May 30, 2006 10:38 AM
Subject: Re: Lucene and Java 1.5

Robert Engels wrote:
> If you need to run on OS9 then run Lucene 1.9 (or it seems 2.0, just 
> not 2.1).
> You have a working, stable release that runs under 1.4. There are MANY 
> applications that don't run under OS9 now (they require OSX). Why 
> should Lucene be any different? I am fairly certain you cannot even 
> purchase OS9 from Apple anymore.
Lucene should be different from other applications because it is different.
Lucene is not an application, it is a service library. It is used by

Java applications are different than other applications. The promise of
"write once, run anywhere" begins to fizzle when "anywhere" is no longer a

I am using a fair number of other apache libraries and none of them require
Java 5. Do any of apache libraries require Java 5? Will Lucene be the first?

For my application ( we provide software that
reads Lucene indexed Bibles. Our clientèle are pastors, missionaries,
students, churches and lay people that have a history of running very old
machines. We are also toying with porting to PDAs and cell phones.

> 1.9 is a fine Lucene release. I suggest stopping 1.4 JDK support at 
> 1.9. 2.0 is bound to have many bug fixes, etc. and having the 
> developers work in 1.4 when everyone else is in 1.5 seems crazy.
2.0 has been released as Java 1.4 compatible. One of the tenets espoused
here is that only a major release will break existing code. It will
otherwise maintain backward compatibility. Based on that Lucene 2.0 should
stay at Java 1.4. (I do believe that is what the other emails in the thread
are agreeing on)

Personally I don't care if contrib maintains backward compatibility and I
don't think that the "backward compatibility rule" was applied to contrib
(at least in the years that I have been lurking here).

When it comes to 2.1, to me it all depends on when it is released. If it
were to be released in the next year, I would not like it as I assume that
2.1 will provide significant performance gains just as 2.0 did and I would
want to provide those advantages to my user base.

Also, the other discussion of gjc seems to suggest that the hopes of a
Lucene 2.1 are pinned on gjc supporting Java 5 features. If gjc
compatibility is a reasonable requisite, then I don't think that it is
reasonable for Lucene to go ahead of it.

> I think the issues like ThreadLocal, etc. which are fixed in the 1.5 
> libraries are reason enough to move.

Are you saying that these were fixed in the API? If so, I think your
argument is a good one. And I think you hit the nail on the head: Java 5
should be considered when it solves a real problem. In this thread the
primary arguments have been on how nice it would be to write in Java 5. 
While I agree it would be nicer, syntactic sugar not solve problems.

But if it is fixed in the JVM, then it can be documented that merely running
Java 5 fixes the ThreadLocal issues. I wholeheartedly recommend running
Java 1.4 applications under a Java 5 jvm. And while I don't like it, I don't
mind telling my user base that the problem they encountered has been
reported and fixed and the solution for them is to put up with the problem
or upgrade.

> You can't get Sun to fix these old JDK issues, why should we be 
> attempting to work around them.

I think that Lucene should be very clear in what it sees as its mission and
its supported community. From this mailing list, I get the impression that
it is primarily one of server side applications. In this case there is some
level of control over the execution environment. My use is client side
application and I don't have much control over the execution environment. I
think it may be constructive to poll the lucene users mailing list as to
what they need.

> -----Original Message-----
> From: DM Smith []
> Sent: Tuesday, May 30, 2006 8:52 AM
> To:
> Subject: Re: Lucene and Java 1.5
> Please don't move to Java 5.
> My reasons are simple (and some perhaps stem out of old information or
> misinformation):
>     MacOS 9 does not run Java 1.5, which is one of my target platforms. 
> Has Java 5 been ported to all target platforms?
>     Java 5 has nice syntax sugar but no real substance other than the 
> stronger type checking.
>         (My opinion based on porting to Java 5 and then back to Java
>     Not all support tooling (e.g. java2html, checkstyle, findbugs, 
> ...) supports Java 5 syntax. This reduces my ability to qa code using 
> these tools.
>     Java 5 moves lucene away from the possibility of ever working on J2ME.
>     Java 5 moves away from running on an open source java, e.g. gjc.
>     The performance benefits of a Java 5 JVM are independent of Java 5 
> source.
>     Going to Java 5 requires all applications using Lucene to upgrade 
> to Java 5.
> Sure Java 5 has been out for a while and Java 6 is around the corner, 
> but ask yourself why it is not the defacto standard version of Java.
> karl wettin wrote:
>> Will code with 1.5 syntax be committed?

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message