Just an FYI that the initial changes for JEP 220 (http://openjdk.java.net/jeps/220) have been pushed to JDK 9 and should appear in the jdk9-b41 build. So tools.jar, rt.jar and dt.jar are gone. Hopefully it's not too hard to update the home directory detection to work with the new modular runtime images.

Reducing priority again as this is only about input validation. Could extend the check mentioned in the description if there is something that would allow identifying a JDK directory. Do you know alternatives to checking presence of these jars that preferably works on all older JDKs as well?

The simplest thing is to check for is bin/javac (or bin\javac.exe). That should work for all releases.

It started out with the tools.jar check (commit lost to history), then added a Mac-specific test in https://github.com/jenkinsci/jenkins/commit/d1b27237707e97095657bd1ef2f0facaf84f32e0 that was modified for JENKINS-533 in https://github.com/jenkinsci/jenkins/commit/aef102cb727fe65305a5f66fc5949096c9a5b473.

It's possible tools.jar was checked because it's easier than platform-dependent javac binary names.

Given that section:

All other files and directories in the lib directory must be treated as private implementation details of the run-time system. They are not intended for external use and their names, format, and content will be subject to change without notice.

The only sensible solution seems to be to check for bin/javac and bin\javac.exe and if neither exists, provide the warning. Keep the existing two checks for compatibility in case there are other javac names on some platforms, they shouldn't hurt anything.

Proposed solution at https://github.com/jenkinsci/jenkins/pull/1499

Would be really helpful if you could download the PR build at https://jenkins.ci.cloudbees.com/job/core/job/jenkins-core/1832/ (assuming it builds successfully) to see whether it works as expected.

Please see comment above for build with proposed fix.

Hi, sorry for the delay.
I build from source (skipping test because of javassist && jdk 8 ) as I did not find a jenkins.war on the cloudbees jenkins instance.

It's working: JDK 9 folder is detected as jdk, and older jdk 7 or jdk 8 are also detected as jdk

Code changed in jenkins
User: Daniel Beck
Path:
core/src/main/java/hudson/model/JDK.java
http://jenkins-ci.org/commit/jenkins/1186e7b4047a70162a1a3be399fc449ae3b0e1f5
Log:
[FIXED JENKINS-25601] Amend JAVA_HOME check to work with JDK 9

Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
core/src/main/java/hudson/model/JDK.java
http://jenkins-ci.org/commit/jenkins/b33b921dc5d4dacdca7a9b73cfbe6f8a57f05307
Log:
JENKINS-25601 Noting merge of #1499.

Compare: https://github.com/jenkinsci/jenkins/compare/75eeccf8668e...b33b921dc5d4

Integrated in jenkins_main_trunk #3923
[FIXED JENKINS-25601] Amend JAVA_HOME check to work with JDK 9 (Revision 1186e7b4047a70162a1a3be399fc449ae3b0e1f5)

Result = SUCCESS
daniel-beck : 1186e7b4047a70162a1a3be399fc449ae3b0e1f5
Files :

• core/src/main/java/hudson/model/JDK.java

Code changed in jenkins
User: Daniel Beck
Path:
core/src/main/java/hudson/model/JDK.java
http://jenkins-ci.org/commit/jenkins/bf6859f059bc809a8b1bae6ef184af56a37f79e0
Log:
[FIXED JENKINS-25601] Amend JAVA_HOME check to work with JDK 9

(cherry picked from commit 1186e7b4047a70162a1a3be399fc449ae3b0e1f5)

Integrated in jenkins_main_trunk #4292
[FIXED JENKINS-25601] Amend JAVA_HOME check to work with JDK 9 (Revision bf6859f059bc809a8b1bae6ef184af56a37f79e0)

Result = UNSTABLE
ogondza : bf6859f059bc809a8b1bae6ef184af56a37f79e0
Files :

• core/src/main/java/hudson/model/JDK.java