[
https://issues.apache.org/jira/browse/CASSANDRA-14926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16717378#comment-16717378
]
Aaron Ploetz commented on CASSANDRA-14926:
------------------------------------------
I'll drop my current patch out here, just so we have it.
> 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: Configuration
> Reporter: Aaron Ploetz
> Assignee: Aaron Ploetz
> Priority: Minor
> Fix For: 4.x
>
>
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
