[
https://issues.apache.org/jira/browse/LUCENE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-3239:
Attachment: LUCENE-3239.patch
here is a patch that fixes almost all todos except of the one in NativeFSLock.
I think for that we should open a sep. issue. I didn't convert all the
ArrayUtils yet I think we can do that later in a followup too.
> drop java 5 "support"
> -
>
> Key: LUCENE-3239
> URL: https://issues.apache.org/jira/browse/LUCENE-3239
> Project: Lucene - Java
> Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-3239.patch, LUCENE-3239.patch
>
>
> 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 (http://wiki.apache.org/lucene-java/SunJavaBugs) 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: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org