Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-25601

JDK9 with jigsaw file layer is not detected as valid JDK

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • - fedora 20. jdk8_25
      - build jigsaw jdk: build 1.9.0-ea-jigsaw-nightly-h1689-20141110-b38, mixed mode

      Hi,
      The new jigsaw jdk is not detected as valid jdk because tools.jar and dt.jar are removed from the lib path but are needed by jenkins for detection.

      file: hudson/model/JDK.java
      method: checkHomeDirectory

      Not sure how to make a nice validation for current and jigsaw jdk.

      As a workaround having void tools.jar and dt.jar allow jdk detection by jenkins.

          [JENKINS-25601] JDK9 with jigsaw file layer is not detected as valid JDK

          Eric Barboni created issue -

          Alan Bateman added a comment -

          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.

          Alan Bateman added a comment - 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.
          Daniel Beck made changes -
          Priority Original: Minor [ 4 ] New: Major [ 3 ]

          Daniel Beck added a comment -

          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?

          Daniel Beck added a comment - 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?
          Daniel Beck made changes -
          Priority Original: Major [ 3 ] New: Minor [ 4 ]

          Alan Bateman added a comment - - edited

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

          Alan Bateman added a comment - - edited The simplest thing is to check for is bin/javac (or bin\javac.exe). That should work for all releases.

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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.
          Daniel Beck made changes -
          Assignee New: Daniel Beck [ danielbeck ]
          Daniel Beck made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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.
          Daniel Beck made changes -
          Remote Link New: This issue links to "PR 1499 (Web Link)" [ 11935 ]

            danielbeck Daniel Beck
            skygo Eric Barboni
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: