Repository navigation
Conversation
* On macOS, use $(shell /usr/libexec/java_home); `$(/usr/libexec/java_home)` is a reference to an undefined make variable, so JAVA_HOME was empty. * Compute JAVA_HOME once, with ":=", and locate javac with a single shell command. * tests/Makefile.common sets JAVA_HOME before including Makefile.user, so the junit and junit5 Makefile.user files no longer duplicate the detection. A missing JDK is reported only when JAVA or JAVAC is expanded, so targets such as "clean" work without a JDK. * java/Makefile fails clearly if no JDK is found.
Detect JAVA_HOME by asking the JVM that runs javac, which handles wrapper scripts and Homebrew JDKs; fall back to /usr/libexec/java_home on macOS. Check that JAVA_HOME contains bin/javac. In the tests, fix the JDK after Makefile.user is included, use it for the version check, and omit nonexistent jars from JAVALIB_CLASSPATH.
java/Makefile and tests/Makefile.common include java/java-home.mk, which asks the JVM that runs javac for its home directory, so that a javac wrapper script (as used by jenv, asdf, or mise) works. If the user set JAVA_HOME, it warns when the javac on the PATH is in a different JDK. scripts/daikon.bashrc uses the same logic. In the tests, the Java version check uses the JDK in JAVA_HOME and is skipped when there is no JDK, so that targets such as "clean" work without one. JAVALIB_CLASSPATH contains only jar files that exist. This incorporates the changes of codespecs#896.
- java-home.mk exports JAVA_HOME, defines CHECKED_JAVA_HOME lazily, and reads JAVA_VERSION_STRING and JAVA_RELEASE_NUMBER from $JAVA_HOME/release. - java/Makefile uses the JDK at JAVA_HOME for java, javac, javadoc, and jar, so the version and the --system directory agree with the compiler. - The PATH-vs-JAVA_HOME warning runs once, after Makefile.user, and only when JAVA_HOME contains a JDK. - tests/Makefile.common includes java-home.mk after Makefile.user and drops TESTS_JAVA_HOME. - daikon.bashrc always exports JAVA_HOME and warns if it is not a JDK. - The staging target fails if Javadoc was not built.
- java-home.mk falls back to "java -version" when the JDK has no "release" file (as in Debian/Ubuntu OpenJDK 8), and fails if a Java installation's version cannot be determined, rather than silently treating it as 0. - java-home.mk defines java_at_least, used by all Makefiles instead of repeated shell tests; the major version is computed without a shell. - JAVA_HOME detection first uses the JDK containing the javac on the PATH, and starts a JVM only if that fails. daikon.bashrc does the same. - DAIKON_JAVA_HOME snapshots JAVA_HOME, so commands and version variables agree even if a Makefile later reassigns JAVA_HOME. - The PATH-vs-JAVA_HOME check also covers java, recognizes JDKs without a "release" file, and reruns when JAVA_HOME or PATH changes. - The top-level Makefile runs java, javac, and jar from JAVA_HOME.
Simplify the detection: follow the javac on the PATH to its JDK, or use /usr/libexec/java_home on macOS, without starting a JVM. Java version computation, using JAVA_HOME's tools, the PATH-vs-JAVA_HOME warning, and small unrelated fixes move to separate pull requests.
java-home.mk defines JAVA_VERSION_STRING, JAVA_RELEASE_NUMBER, and the function java_at_least. They replace the separate version computations in the top-level Makefile, java/Makefile, and tests/Makefile.common, which used whichever java or javac was on the PATH.
|
Warning Review limit reached
This review includes 7 billable files and costs up to $1.75. Or wait 7 minutes for your next included review. View limit details
Comment |
This was referenced Oct 11, 2026
Member
Author
|
Superseded by #897, which now computes the Java version (once, and cached across recursive makes) from the JDK at JAVA_HOME. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds on #897; until that is merged, this pull request also shows its changes. The new commit is "Compute the Java version once, from the JDK at JAVA_HOME".
The top-level Makefile,
java/Makefile, andtests/Makefile.commoneach computed the Java version differently, from whicheverjavaorjavacwas on thePATH. Nowjava/java-home.mkdefinesJAVA_VERSION_STRING,JAVA_RELEASE_NUMBER, and the functionjava_at_least, from the JDK atJAVA_HOME, and all three Makefiles use them.The version comes from
java -version, which works for JDKs that lack areleasefile (such as Debian and Ubuntu's OpenJDK 8). IfJAVA_HOMEcontains a JDK whose version cannot be determined, make fails.