[ 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org