Found reviewing PR #232 (Windows JDK bootstrap). Verified against install.ps1 as merged.
What happens
The generated .bat launcher now resolves Java as:
if exist "%BASE_DIR%\jdk\bin\java.exe" set "JAVA_HOME=%BASE_DIR%\jdk"
if defined JAVA_HOME if exist "%JAVA_HOME%\bin\java.exe" set "PATH=%JAVA_HOME%\bin;%PATH%"
(install.ps1:859-860 in the here-string). When the installer did not bundle a JDK — the normal case on a host that already had a good Java — the first line does nothing and the second still prepends whatever %JAVA_HOME% happens to point at, ahead of the PATH.
It then computes JAVA_MAJOR, and uses it only to decide the --add-opens flags:
if %JAVA_MAJOR% GEQ 9 set EXTRA_OPTS=--add-opens=...
%REQUIRED_JAVA% is set at the top of the file and appears exactly once more: in the "Java is not installed" message. The .bat never compares the two.
The .ps1 launcher does:
if ($javaVersion -gt 0 -and $javaVersion -lt $RequiredJava) {
Write-Error "Java $RequiredJava+ is required. Found: Java $javaVersion"
exit 1
}
So the two generated launchers disagree about a check the whole install depends on.
Consequence
A user whose PATH has Java 17 and whose JAVA_HOME points at a Java 8 JRE (a common state on Windows — an old JDK install, or another tool that set it) now runs the REPL on Java 8 and gets UnsupportedClassVersionError. Before this change the launcher used the PATH java and worked. The error names a class file version, not a JAVA_HOME problem, so it reads as a broken install.
Suggested fix
Add the version comparison to the .bat template, mirroring the .ps1 one:
if %JAVA_MAJOR% LSS %REQUIRED_JAVA% (
echo Error: Java %REQUIRED_JAVA%+ is required. Found: Java %JAVA_MAJOR% >&2
exit /b 1
)
Worth deciding at the same time whether %JAVA_HOME% should really outrank the PATH when no JDK was bundled, or only when it satisfies %REQUIRED_JAVA%. The installer's own comment ("Probing the PATH java when JAVA_HOME is set would validate a JVM the REPL is never going to run") argues for keeping the order and adding the check.
Found reviewing PR #232 (Windows JDK bootstrap). Verified against
install.ps1as merged.What happens
The generated
.batlauncher now resolves Java as:(install.ps1:859-860 in the here-string). When the installer did not bundle a JDK — the normal case on a host that already had a good Java — the first line does nothing and the second still prepends whatever
%JAVA_HOME%happens to point at, ahead of the PATH.It then computes
JAVA_MAJOR, and uses it only to decide the--add-opensflags:%REQUIRED_JAVA%is set at the top of the file and appears exactly once more: in the "Java is not installed" message. The.batnever compares the two.The
.ps1launcher does:So the two generated launchers disagree about a check the whole install depends on.
Consequence
A user whose PATH has Java 17 and whose
JAVA_HOMEpoints at a Java 8 JRE (a common state on Windows — an old JDK install, or another tool that set it) now runs the REPL on Java 8 and getsUnsupportedClassVersionError. Before this change the launcher used the PATHjavaand worked. The error names a class file version, not aJAVA_HOMEproblem, so it reads as a broken install.Suggested fix
Add the version comparison to the
.battemplate, mirroring the.ps1one:Worth deciding at the same time whether
%JAVA_HOME%should really outrank the PATH when no JDK was bundled, or only when it satisfies%REQUIRED_JAVA%. The installer's own comment ("Probing the PATH java when JAVA_HOME is set would validate a JVM the REPL is never going to run") argues for keeping the order and adding the check.