Details
-
Bug
-
Status: Resolved
-
Low
-
Resolution: Won't Fix
-
None
-
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.