RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles

[Alexander Matveev]

On Tue, 20 May 2025 16:39:02 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Fixed jpackage to produce valid Java runtimes based on description below:
>> 
>> Definitions:
>> 
>> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist".
>> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature".
>> - JDK image defined as content of "Contents/Home".
>> - Signed JDK image does not exist, since it cannot be signed as bundle.
>> 
>> jpackage output based on input:
>> 
>> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path and run ad-hoc codesign.
>> 
>> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image.
>>  
>> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing.
>> 
>> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided:
>> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate.
>> 
>> 5. "--runtime-image" points to JDK image and --mac-sign is not provided:
>>  - jpackage will check for libjli.dylib presence in "lib" folder.
>>  - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image.
>> - Ad-hoc signing will done.
>> 
>> 6. "--runtime-image" points to JDK image and --mac-sign is provided:
>> - 2 first steps from 5 and certificate signing will be done.
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 246:
> 
>> 244: 
>> 245:     public static String getPropertyFromFile(Path filename, String name) {
>> 246:         // load properties file
> 
> That is a bad idea to expose jpackage API that uses jpackage's Log class. Where will these log messages go?

Fixed.

> src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 251:
> 
>> 249:             properties.load(reader);
>> 250:         } catch (IOException e) {
>> 251:             Log.error("Exception: " + e.getMessage());
> 
> This is an exception swallow, not good. Logging it in place doesn't make it right. If this is an unrecoverable error, it should be forwarded to the caller.

Fixed. Yes, we should consider it as an unrecoverable error.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099133805
PR Review Comment: https://git.openjdk.org/jdk/pull/25314#discussion_r2099134380