Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-ALPHA
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New, Patch Available

      Description

      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.

      1. LUCENE-3239.patch
        13 kB
        Simon Willnauer
      2. LUCENE-3239.patch
        15 kB
        Simon Willnauer

        Issue Links

          Activity

          Hide
          Uwe Schindler added a comment -

          As said yesterday to you privately: I agree with making Lucene trunk Java 6 only - Surprise. But 3.x should stay with Java 5. Is this ok for you?

          I know, Simon will not agree because he made DocValues for Android g

          About Hudson testing: We may donate a machine to Infra just for Lucene tests running something nice like Ubuntu, stay tuned (no details, I just say that).

          Show
          Uwe Schindler added a comment - As said yesterday to you privately: I agree with making Lucene trunk Java 6 only - Surprise. But 3.x should stay with Java 5. Is this ok for you? I know, Simon will not agree because he made DocValues for Android g About Hudson testing: We may donate a machine to Infra just for Lucene tests running something nice like Ubuntu, stay tuned (no details, I just say that).
          Hide
          Robert Muir added a comment -

          About Hudson testing: We may donate a machine to Infra just for Lucene tests running something nice like Ubuntu, stay tuned (no details, I just say that).

          And when this time comes, we could consider supporting java 5.

          But right now, we don't have a way to test it.

          Show
          Robert Muir added a comment - About Hudson testing: We may donate a machine to Infra just for Lucene tests running something nice like Ubuntu, stay tuned (no details, I just say that). And when this time comes, we could consider supporting java 5. But right now, we don't have a way to test it.
          Hide
          DM Smith added a comment -

          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.

          Show
          DM Smith added a comment - 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.
          Hide
          Mark Miller added a comment -

          That seems reasonable to me - officially we endorse/support java 6, but we can the 3.x line to 5 features. I can live with that myself.

          Show
          Mark Miller added a comment - That seems reasonable to me - officially we endorse/support java 6, but we can the 3.x line to 5 features. I can live with that myself.
          Hide
          Robert Muir added a comment -

          +1, this seems like a good compromise.

          So let me make sure we are on the same page:

          • trunk moves to java6 (all of the source tree, not just solr/)
          • branch_3x stays the same (limit ourselves to what compiles with java5), its already the de-facto reality that java5 is not officially supported since we do not even test it.
          Show
          Robert Muir added a comment - +1, this seems like a good compromise. So let me make sure we are on the same page: trunk moves to java6 (all of the source tree, not just solr/) branch_3x stays the same (limit ourselves to what compiles with java5), its already the de-facto reality that java5 is not officially supported since we do not even test it.
          Hide
          DM Smith added a comment -

          Same page.

          Show
          DM Smith added a comment - Same page.
          Hide
          Simon Willnauer added a comment - - edited

          So let me make sure we are on the same page:

          +1

          we should call out an official vote on the dev list though

          Show
          Simon Willnauer added a comment - - edited So let me make sure we are on the same page: +1 we should call out an official vote on the dev list though
          Hide
          Dawid Weiss added a comment -

          +1 from me.

          Show
          Dawid Weiss added a comment - +1 from me.
          Hide
          Simon Willnauer added a comment -

          this patch moves the build and metadata to 1.6

          Show
          Simon Willnauer added a comment - this patch moves the build and metadata to 1.6
          Hide
          Uwe Schindler added a comment -

          Patch looks fine, Jenkins already moved.

          Show
          Uwe Schindler added a comment - Patch looks fine, Jenkins already moved.
          Hide
          Simon Willnauer added a comment -

          I just committed that patch, I will continue on all the *.java TODOs

          Show
          Simon Willnauer added a comment - I just committed that patch, I will continue on all the *.java TODOs
          Hide
          Simon Willnauer added a comment -

          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.

          Show
          Simon Willnauer added a comment - 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.
          Hide
          Uwe Schindler added a comment -

          +1 as a start

          Show
          Uwe Schindler added a comment - +1 as a start
          Hide
          Simon Willnauer added a comment -

          +1 as a start

          alright I'll kick it in... we are on 1.6 YAY!

          Show
          Simon Willnauer added a comment - +1 as a start alright I'll kick it in... we are on 1.6 YAY!
          Hide
          Simon Willnauer added a comment -

          moving out here, created LUCENE-3265 and LUCENE-3266 as followup issues

          Show
          Simon Willnauer added a comment - moving out here, created LUCENE-3265 and LUCENE-3266 as followup issues

            People

            • Assignee:
              Simon Willnauer
              Reporter:
              Robert Muir
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development