RFR: 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v3]

Alexander Matveev almatvee at openjdk.org
Fri Sep 26 20:22:21 UTC 2025


On Fri, 26 Sep 2025 12:07:31 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8356047
>>  - 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts [v2]
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8356047
>>  - 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts
>
> src/jdk.jpackage/unix/classes/jdk/jpackage/internal/PackageScripts.java line 81:
> 
>> 79:     static class ResourceConfig {
>> 80: 
>> 81:         ResourceConfig(String defaultName, String categoryId, boolean noDefault) {
> 
> Don't you think `String defaultName, String categoryId, boolean noDefault` signature looks odd? You have a parameter specifying the default name and another parameter that specifies if the default name is set or not.
> 
> Wouldn't:
> 
> ResourceConfig(Optional<String> defaultName, String categoryId)
> 
> be less confusing?
> 
> For backward compatibility keep the old ctor, but redefine it:
> 
> ResourceConfig(String defaultName, String categoryId) {
>     this(Optional.of(defaultName), categoryId);
> }

In your suggested case how `ResourceConfig.getDefaultPublicName()` will figure out public name for resource if `defaultName` is not provided? Maybe `String resourceName, String categoryId, boolean noDefault` will be less confusing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25510#discussion_r2383411402


More information about the core-libs-dev mailing list