If a user has set their %JAVA_HOME% env variable on Windows but the %PATH% variable has a different Java version for the runtime and is lower than the compiled class file version 55.0 (Java 11) then users will notice an error and failure during startup even though the Java version check was successful.
To Reproduce
Steps to reproduce the behavior:
- First, set
%JAVA_HOME% to a path having Java 8 Update 333
- Keep
%PATH% env variable set to Java 11 runtime
- Then, run
refine.bat
Current Results
E:\GitHub Repos\OpenRefine>refine
Using refine.ini for configuration
Getting Java Version...
openjdk version "11.0.14.1" 2022-02-08
OpenJDK Runtime Environment Temurin-11.0.14.1+1 (build 11.0.14.1+1)
OpenJDK 64-Bit Server VM Temurin-11.0.14.1+1 (build 11.0.14.1+1, mixed mode)
=====================================================
Getting Free Ram...
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/google/refine/Refine has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
Expected Behavior
Windows
Since we now really depend on %JAVA_HOME% when setting the CLASSPATH in the refine.bat script for Windows, we should fully use %JAVA_HOME% for the Java version inspection and logging to support.log.
We currently have good support for checking the Java versions we support and reporting errors in our refine script for Linux and should ideally incorporate that checkJavaMajorVersion() functionality and adapt it into our refine.bat script for Windows. That way we are consistent with our Java error messaging to users on both platforms.
Linux
One of the additional things in the refine Linux script seems to be that we are not using the $JAVA_HOME env variable during the checkJavaMajorVersion() either but instead always a $JAVA variable. We should ideally always refer to and use $JAVA_HOME as a best practice in our version checking and classpath setup for refine startup, no matter the OS, since that is standard practice and gives users the ability to control their own Java environment or symbolically link to a different one.
Screenshots
Versions
- Operating System: Windows 11 and Linux
- Browser Version: Edge latest and Chrome
- JRE or JDK Version: openjdk version "11.0.14.1" 2022-02-08
- OpenRefine: master branch
Datasets
Additional context
If a user has set their
%JAVA_HOME%env variable on Windows but the%PATH%variable has a different Java version for the runtime and is lower than the compiled class file version 55.0 (Java 11) then users will notice an error and failure during startup even though the Java version check was successful.To Reproduce
Steps to reproduce the behavior:
%JAVA_HOME%to a path having Java 8 Update 333%PATH%env variable set to Java 11 runtimerefine.batCurrent Results
Expected Behavior
Windows
Since we now really depend on
%JAVA_HOME%when setting the CLASSPATH in therefine.batscript for Windows, we should fully use %JAVA_HOME% for the Java version inspection and logging to support.log.We currently have good support for checking the Java versions we support and reporting errors in our
refinescript for Linux and should ideally incorporate thatcheckJavaMajorVersion()functionality and adapt it into ourrefine.batscript for Windows. That way we are consistent with our Java error messaging to users on both platforms.Linux
One of the additional things in the
refineLinux script seems to be that we are not using the$JAVA_HOMEenv variable during thecheckJavaMajorVersion()either but instead always a$JAVAvariable. We should ideally always refer to and use$JAVA_HOMEas a best practice in our version checking and classpath setup for refine startup, no matter the OS, since that is standard practice and gives users the ability to control their own Java environment or symbolically link to a different one.Screenshots
Versions
Datasets
Additional context