Lucene - Core
  1. Lucene - Core
  2. LUCENE-3574

Add some more constants for newer Java versions to Constants.class, remove outdated ones.

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.5, 4.0-ALPHA
    • Component/s: core/other
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Preparation for LUCENE-3235:
      This adds constants to quickly detect Java6 and Java7 to Constants.java. It also deprecated and removes the outdated historical Java versions.

        Issue Links

          Activity

          Hide
          Uwe Schindler added a comment -

          Patch for Lucene 3.x

          will remove deprecations in trunk and make JRE_IS_MINIMUM_JRE6 = true (+ deprecate it there)

          Show
          Uwe Schindler added a comment - Patch for Lucene 3.x will remove deprecations in trunk and make JRE_IS_MINIMUM_JRE6 = true (+ deprecate it there)
          Hide
          Uwe Schindler added a comment -

          Committed 3.x revision: 1201739

          Show
          Uwe Schindler added a comment - Committed 3.x revision: 1201739
          Hide
          Uwe Schindler added a comment -

          Committed trunk revision: 1201741

          Show
          Uwe Schindler added a comment - Committed trunk revision: 1201741
          Hide
          Shai Erera added a comment -

          One typo: "nsme" -> "name"

          Also, not sure if it's worth it, but perhaps instead of constants like MIMINUM_JAVA_X we can have a class JavaVersion that follows the same logic we have in Version and can compare itself to other JavaVersions? Then we can have constants for JAVA_6 = new JavaVersion(6) and similar for JAVA_7, and another CURRENT_JAVA_VER that is initialized with the code you wrote. And you can then compare CURRENT to JAVA_6/7?

          Just an idea.

          Show
          Shai Erera added a comment - One typo: "nsme" -> "name" Also, not sure if it's worth it, but perhaps instead of constants like MIMINUM_JAVA_X we can have a class JavaVersion that follows the same logic we have in Version and can compare itself to other JavaVersions? Then we can have constants for JAVA_6 = new JavaVersion(6) and similar for JAVA_7, and another CURRENT_JAVA_VER that is initialized with the code you wrote. And you can then compare CURRENT to JAVA_6/7? Just an idea.
          Hide
          Robert Muir added a comment -

          Also, not sure if it's worth it, but perhaps instead of constants like MIMINUM_JAVA_X we can have a class JavaVersion that follows the same logic we have in Version

          I think the problem here would be that say we release 3.5 in a week.

          Then two years later Java 8 comes out... we can't know today how to detect it. So all we can do is say that we are 'at least' java 7 because we have XYZ.

          Show
          Robert Muir added a comment - Also, not sure if it's worth it, but perhaps instead of constants like MIMINUM_JAVA_X we can have a class JavaVersion that follows the same logic we have in Version I think the problem here would be that say we release 3.5 in a week. Then two years later Java 8 comes out... we can't know today how to detect it. So all we can do is say that we are 'at least' java 7 because we have XYZ.
          Hide
          Uwe Schindler added a comment -

          One typo: "nsme" -> "name"

          nsme -> NoSuchMethodException

          Show
          Uwe Schindler added a comment - One typo: "nsme" -> "name" nsme -> NoSuchMethodException
          Hide
          Shai Erera added a comment -

          Exactly (I think that's what I meant) – we detect the Java version as best we can and store it in a constant JAVA_VERSION. It can be compared to JAVA_6/7 thru an atLeast() API, like JAVA_VERSION.atLeast(JAVA_7).

          The code in 3.5 will only know to detect up to Java 7, while the code in 5.2 will know to detect Java 8.

          Wouldn't that work?

          Show
          Shai Erera added a comment - Exactly (I think that's what I meant) – we detect the Java version as best we can and store it in a constant JAVA_VERSION. It can be compared to JAVA_6/7 thru an atLeast() API, like JAVA_VERSION.atLeast(JAVA_7). The code in 3.5 will only know to detect up to Java 7, while the code in 5.2 will know to detect Java 8. Wouldn't that work?
          Hide
          Shai Erera added a comment -

          nsme -> NoSuchMethodException

          ah, ok .

          Show
          Shai Erera added a comment - nsme -> NoSuchMethodException ah, ok .
          Hide
          Robert Muir added a comment -

          The code in 3.5 will only know to detect up to Java 7, while the code in 5.2 will know to detect Java 8.

          Wouldn't that work?

          I would prefer not to, because it opens up the opportunity to wrongly record this somewhere (e.g. diagnostics map)
          or even just System.out.println or checkindex or something... it would be misleading.

          Show
          Robert Muir added a comment - The code in 3.5 will only know to detect up to Java 7, while the code in 5.2 will know to detect Java 8. Wouldn't that work? I would prefer not to, because it opens up the opportunity to wrongly record this somewhere (e.g. diagnostics map) or even just System.out.println or checkindex or something... it would be misleading.
          Hide
          Uwe Schindler added a comment -

          One example where it might be bad: If it's an enum, you can also do if (JAVA_VERSION==JAVA_7, so the enum constants are not named like the fact they represent.

          I think thats all too much logic for something simple. For one major version we will have mostly 2 or 3 constants. In trunk we currently only have Java7 and a deprecated one which is always true. New constants are only added on request, when we want to test for features/bugs.

          Show
          Uwe Schindler added a comment - One example where it might be bad: If it's an enum, you can also do if (JAVA_VERSION==JAVA_7, so the enum constants are not named like the fact they represent. I think thats all too much logic for something simple. For one major version we will have mostly 2 or 3 constants. In trunk we currently only have Java7 and a deprecated one which is always true. New constants are only added on request, when we want to test for features/bugs.
          Hide
          Shai Erera added a comment -

          Ok I'm convinced . Was just a thought

          Show
          Shai Erera added a comment - Ok I'm convinced . Was just a thought
          Hide
          Uwe Schindler added a comment -

          Bulk close after release of 3.5

          Show
          Uwe Schindler added a comment - Bulk close after release of 3.5

            People

            • Assignee:
              Uwe Schindler
              Reporter:
              Uwe Schindler
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development