lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DM Smith (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3239) drop java 5 "support"
Date Fri, 24 Jun 2011 18:45:47 GMT


DM Smith commented on LUCENE-3239:

Hey, it's me, old-stick-in-the-mud, wrt upgrading Java :) For the most part, I think the same
arguments as last time (Java 1.4 -> Java 5) still apply.

However, Oracle is so much more aggressive in obsoleting their software. They haven't patched
Java 5 in quite some time. When Lucene went to Java 5, Java 1.4 was still being patched.

I think most will be running Lucene under Java 6 (excepting some versions of Mac OS X and
hardware. E.g. Core Duo Macs can't run Java 6).

I'd like to see that we have api compatibility w/ Java 5 (i.e. it can compile against Java
5), but certify against Java 6. This would allow it to run under Java 5, with the appropriate
caveats that it is not supported or tested.

If you do go to Java 6 features, then I think it has to be a 4.0 release and the planned 4.0
might need to be bumped to a 5.0 designation.

> drop java 5 "support"
> ---------------------
>                 Key: LUCENE-3239
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Task
>            Reporter: Robert Muir
> its been discussed here and there, but I think we need to drop java 5 "support", for
these reasons:
> * its totally untested by any continual build process. Testing java5 only when there
is a release candidate ready is not enough. If we are to claim "support" then we need a hudson
actually running the tests with java 5.
> * its now unmaintained, so bugs have to either be hacked around, tests disabled, warnings
placed, but some things simply cannot be fixed... we cannot actually "support" something that
is no longer maintained: we do find JRE bugs (
and its important that bugs actually get fixed: cannot do everything with hacks.
> * because of its limitations, we do things like allow 20% slower grouping speed. I find
it hard to believe we are sacrificing performance for this.
> So, in summary: because we don't test it at all, because its buggy and unmaintained,
and because we are sacrificing performance, I think we need to cutover the build system for
the next release to require java 6.

This message is automatically generated by JIRA.
For more information on JIRA, see:


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

View raw message