Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-14926

OpenJDK - Using 1.8.0 "adoptopenjdk" throws error from command line

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Low
    • Resolution: Won't Fix
    • Fix Version/s: 4.x
    • Component/s: Local/Config
    • Labels:
      None
    • Severity:
      Low

      Description

      When testing with a recent build of 4.0, I noticed that Cassandra commands from my Mac (nodetool, bin/cassandra) was throwing a Bash syntax error:

      bin/cassandra.in.sh: line 115: [: 1.8.0: integer expression expected

      The offending line (115 in cassandra.in.sh) is this:

      if [ "$JVM_PATCH_VERSION" -lt 151 ] ; then

      Essentially, the patch version of the JDK is being parsed and then verified to be higher than 1.8.0_151.  The value of $JVM_PATCH_VERSION is assumed to be numeric.  Further investigation revealed this to be specific to the OpenJDK version on my Mac (our test CentOS clusters are fine).

      On CentOS, the JDK version reads like this:

      {{}}{{$ java -version
      openjdk version "1.8.0_191"
      OpenJDK Runtime Environment (build 1.8.0_191-b12)
      OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)}}

      {{}}But when I check the JDK version on my Mac, I see this:

      {{$ java -version
      openjdk version "1.8.0-adoptopenjdk"
      OpenJDK Runtime Environment (build 1.8.0-adoptopenjdk-jenkins_2018_05_19_02_01-b00)
      OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)}}

      This output causes the $JVM_PATCH_VERSION to resolve to "1.8.0."  Obviously not a valid integer.

      I messed around with adding an extra if-check prior to the line in-question:

      if [[ "$JVM_PATCH_VERSION" =~ ^[0-9]+$ ]] ; then

      This suppresses the error, but doesn't really validate an adequate patch level (which is the true goal here).  The problem with this OpenJDK version, is that we'd have to take a different approach in obtaining the patch version.  I wonder how prevalent the "adoptopenjdk" versions are out there to begin with, and if simply suppressing this error is fine for this edge case?  Or is it worth the extra digging to pull in the patch version in this case?

      Note: This is not an issue prior to 4.0, due to the changes made in the cassandra.in.sh file.

        Attachments

        1. 14926-trunk.patch
          1 kB
          Aaron Ploetz

          Activity

            People

            • Assignee:
              aploetz Aaron Ploetz
              Reporter:
              aploetz Aaron Ploetz
              Authors:
              Aaron Ploetz
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: