Comparable version string is not comparable

[steve-in-ont]

The output of the comparableJavaVersionNumber() function is used to compare JRE versions, but the strings produced are then compared using the "-ge" operator which does a numeric comparison, NOT a lexical comparison. To illustrate with an example, here's the output version strings I get for the JDK versions installed on my Mac:

Version 1.6.0_65 results in "6065"
Version 1.7.0_45 results in "7045"
Version 1.8.0_101 results in "80101"
Version 9 results in "9"

When comparing the output strings all versions less than version 9 are considered greater than version 9. Also, because a 3 digit patch number results in a 5-digit version string, a 1.7 level JRE (for example) with patch number greater than 100 would have a larger version string than a 1.8 level JRE with a patch number less than 100.

Perhaps normalizing the length of the version string to 6 or 7 digits would fix the problem. This would result in strings like:

"606500"
"704500"
"801010"
"900000"

These are directly comparable using the "-ge" operator.

[tofi86]

Hi Steve,

did you find this while reading the source code or did you run into an issue with a specific configuration in your Info.plist file?

From a quick review of the code, the function is only used in contexts where only the extracted major versions are compared (e.g. 9-ge10=false; 8-ge7=true; etc.).

If you think the script picked up a wrong JDK for your JVM requirement, please provide an example.

[steve-in-ont]

Hi Tobias,

In the instance I was testing the JAVA_HOME variable was not set and the JVM version was not set in the Info.plist file. This results in the stub script performing the checks in the section starting with the comment:

# otherwise check "/usr/libexec/java_home" and Oracle and Apple JRE paths and use highest version available

On my system I have all of the JRE's installed as indicated in my previous message, from version 1.6 through Java 9. There are 3 checks in this section of the stub. The first uses the "java_home" tool and sets the JAVACMD variable for the version 9 JRE (as expected). The second checks the Oracle JRE plugin and also sets the JAVACMD variable for the version 9 JRE (as expected).

The problem occurs in the third check where the Apple JRE plugin is tested. The version number is retrieved with the "comparableJavaVersionNumber" function (NOT the "extractJavaMajorVersion" function!) which returns "6065" corresponding to the version 1.6 JRE. This is compared with the value of the "JAVACMD_version" variable which is "9". Since 6065 -ge 9 is true the stub decides that the version 1.6 JRE is the most recent, resulting in a "UnsupportedClassVersionError" exception when it attempts to start the Java application since the application was compiled for version 1.8.

It appears that the section that checks the Info.plist file uses the major version number for comparisons, but the following section does not. Hope that helps.

[tofi86]

Hi Steve,

indeed, that's a bug and I was able to reproduce it.

I added basic logging with #49 in order to be able to better debug the stub in the future.

A fix is underway... :)

[steve-in-ont]

Great! Thanks for the update.

[tofi86]

Hi Steve,

I pushed another set of refactoring changes to the develop branch. The main part of the refactoring should be done now. Not all was necessary to fix this isse here, but I felt better with a bigger refactoring, making functions more robust, changing Java version number comparison in general, adding logging, etc. and also adding some more testcases for the functions.

Any chance you can test the current stub file from develop branch in your environment and tell me whether it works or not? thanks!

[steve-in-ont]

Hi Tobias,

The new version seems to be selecting the correct JRE now. When JAVA_HOME is not set it's now choosing the Java 9 JRE rather than the Java 1.6 JRE. If I find any other problems I'll let you know.

[tofi86]

Great! Thanks for testing the dev version! 🥇 🎉

[tofi86]

This fix has been released with version 3.0.0 right now... Thanks for reporting it 👍