Michael Semb Wever updated CASSANDRA-14926:
    Status: Open  (was: Patch Available)

> OpenJDK - Using 1.8.0 "adoptopenjdk" throws error from command line
> -------------------------------------------------------------------
>                 Key: CASSANDRA-14926
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14926
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local/Config
>            Reporter: Aaron Ploetz
>            Assignee: Aaron Ploetz
>            Priority: Low
>             Fix For: 4.x
>         Attachments: 14926-trunk.patch
> 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.

This message was sent by Atlassian Jira

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to