P4
jpackage produces Java runtime DMG bundles that can't be used as-is.
Michael Hall reported a problem at [1] and created a detailed report on his experience at [2].
The takeaways are:
1. Runtime DMG bundle missing "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" directory;
2. /usr/libexec/java_home doesn't detect this installed runtime DMG bundle. This is likely due to issue #1.
I tried to create a runtime DMG bundle using the latest jpackage (JDK25) from the official OpenJDK JDK21 archvie [3]:
jpackage --runtime-image jdk-21.0.2.jdk --type dmg --name 'custom-jdk-21'
It produced "custom-jdk-21-1.0.dmg" bundle that I successfully "installed" (copied using Finder) into "/Library/Java/JavaVirtualMachines" subtree. I confirm the observations listed above. Even though the archive at [3] contains "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, they were stripped from the DMG bundle jpackage produced.
jpackage produces DMG runtime bundles that can't be used as is. They are missing essential macos bundle files and are not recognized by /usr/libexec/java_home as Java runtimes when installed. I guess the same applies to PKG bundles.
Suggested fixes for runtime packaging:
1. If --runtime-image references a directory that has "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, jpackage should copy them as-is.
2. If --runtime-image references a directory without "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, jpackage should create them.
3. If the --app-version option is specified, jpackage should use it similarly to how it uses it for app bundling.
4. If the --app-version option is NOT specified, jpackage should obtain the bundle version from the JAVA_VERSION property of JDK's "release" file if it is available instead of using the default "1.0" value.
The overall goal of the suggested changes is to make jpackage produce valid runtime bundles recognized by /usr/libexec/java_home when installed.
[1] https://mail.openjdk.org/pipermail/core-libs-dev/2025-February/140696.html
[2] http://mikehall.pairserver.com/sysjdk.html
[3] https://download.java.net/java/GA/jdk21.0.2/f2283984656d49d69e91c558476027ac/13/GPL/openjdk-21.0.2_macos-x64_bin.tar.gz
Michael Hall reported a problem at [1] and created a detailed report on his experience at [2].
The takeaways are:
1. Runtime DMG bundle missing "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" directory;
2. /usr/libexec/java_home doesn't detect this installed runtime DMG bundle. This is likely due to issue #1.
I tried to create a runtime DMG bundle using the latest jpackage (JDK25) from the official OpenJDK JDK21 archvie [3]:
jpackage --runtime-image jdk-21.0.2.jdk --type dmg --name 'custom-jdk-21'
It produced "custom-jdk-21-1.0.dmg" bundle that I successfully "installed" (copied using Finder) into "/Library/Java/JavaVirtualMachines" subtree. I confirm the observations listed above. Even though the archive at [3] contains "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, they were stripped from the DMG bundle jpackage produced.
jpackage produces DMG runtime bundles that can't be used as is. They are missing essential macos bundle files and are not recognized by /usr/libexec/java_home as Java runtimes when installed. I guess the same applies to PKG bundles.
Suggested fixes for runtime packaging:
1. If --runtime-image references a directory that has "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, jpackage should copy them as-is.
2. If --runtime-image references a directory without "Contents/MacOS/libjli.dylib", "Contents/Info.plist" files, and "Contents/_CodeSignature" elements, jpackage should create them.
3. If the --app-version option is specified, jpackage should use it similarly to how it uses it for app bundling.
4. If the --app-version option is NOT specified, jpackage should obtain the bundle version from the JAVA_VERSION property of JDK's "release" file if it is available instead of using the default "1.0" value.
The overall goal of the suggested changes is to make jpackage produce valid runtime bundles recognized by /usr/libexec/java_home when installed.
[1] https://mail.openjdk.org/pipermail/core-libs-dev/2025-February/140696.html
[2] http://mikehall.pairserver.com/sysjdk.html
[3] https://download.java.net/java/GA/jdk21.0.2/f2283984656d49d69e91c558476027ac/13/GPL/openjdk-21.0.2_macos-x64_bin.tar.gz