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