You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current java install on UNIX platforms puts a symlink into /usr/lib/jvm/jdk-XX (except JDK 8 which uses /usr/lib/jvm/jdk8) This issue is proposing changing that to /usr/lib/jvm/jdkXX for two reasons:
It will make the other versions consistent with JDK8
The openjdk build process will, by default, search in /usr/lib/jvm/jdkXX for a suitable boot JDK, so it would make our configurations more standardised and potentially reduce the amount of logic needed in the platform-specific-configuration scripts scripts.
e.g.
configure: Found potential Boot JDK using well-known locations (in /usr/lib/jvm/jdk11)
checking for Boot JDK... /usr/lib/jvm/jdk11
checking Boot JDK version... openjdk version "11.0.18" 2023-01-17 OpenJDK Runtime Environment Temurin-11.0.18+10 (build 11.0.18+10) OpenJDK 64-Bit Server VM Temurin-11.0.18+10 (build 11.0.18+10, mixed mode)
The decision here would need to be based on whether we want to be explicit about the boot JDK used (And we generally do use "one version back" which would be inconsistent with the autodetection) - or let it be autodetected (with the note that configure can still pick up things like /usr/lib/jvm/jdk-11.0.18+10 even without the short version)
This is partially driven by the fact that many of our static docker containers are set up with /usr/lib/jvm/jdk17 as the jenkins agent VM so we should aim to be consistent one way or another.
Given that the autodetection will pick up a full path like /usr/lib/jvm/jdk-11.0.18+10 regardless, I don't think there's a disadvantage to allowing /usr/lib/jvm/jdk11 and would recommend we change what's in the playbooks and build scripts to use that path.
The text was updated successfully, but these errors were encountered:
The current java install on UNIX platforms puts a symlink into
/usr/lib/jvm/jdk-XX
(except JDK 8 which uses/usr/lib/jvm/jdk8
) This issue is proposing changing that to/usr/lib/jvm/jdkXX
for two reasons:/usr/lib/jvm/jdkXX
for a suitable boot JDK, so it would make our configurations more standardised and potentially reduce the amount of logic needed in theplatform-specific-configuration
scripts scripts.e.g.
The decision here would need to be based on whether we want to be explicit about the boot JDK used (And we generally do use "one version back" which would be inconsistent with the autodetection) - or let it be autodetected (with the note that configure can still pick up things like
/usr/lib/jvm/jdk-11.0.18+10
even without the short version)This is partially driven by the fact that many of our static docker containers are set up with
/usr/lib/jvm/jdk17
as the jenkins agent VM so we should aim to be consistent one way or another.Given that the autodetection will pick up a full path like
/usr/lib/jvm/jdk-11.0.18+10
regardless, I don't think there's a disadvantage to allowing/usr/lib/jvm/jdk11
and would recommend we change what's in the playbooks and build scripts to use that path.The text was updated successfully, but these errors were encountered: