JDK-8217895 : jpackage --identifer purpose
  • Type: Bug
  • Component: tools
  • Sub-Component: jpackage
  • Affected Version: internal
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-01-28
  • Updated: 2019-09-27
  • Resolved: 2019-04-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
internalFixed
Related Reports
Relates :  
Description
The jpackage --help and JEP 343 make a strong statement that the format of the value must be a reverse domain notation.
However, there is no enforcement and its not clear how the value is used and on which OS's it is significant.

Is it necessary or can it be removed to simplify the command arguments.
Comments
Basically, at least for now, the decision is to retain --identifier option while reducing it's unused impact. webrev: http://cr.openjdk.java.net/~herrick/8217895/ the fix: 1.) updates the help text for --identifier 2.) removes "app.preference.id" from the ".cfg" file and all use of it in the native launcher. 3.) removes obsolete code to read ".cfg" as a properties file.
12-04-2019

The help text for --identifier: --identifier <id string> Machine readable identifier of the application The format must be a DNS name in reverse order, such as com.example.myapplication. should be softened and enhanced. I propose: --identifier <id string> An identifier that uniquely identifies the application Defaults to the main class name. The value should be a valid DNS name.
11-04-2019

the help text for --mac-bundle-identifier says: --mac-bundle-identifier <ID string> An identifier that uniquely identifies the application for MacOSX (and on the Mac App Store) May only use alphanumeric (A-Z,a-z,0-9), hyphen (-), and period (.) characters. propose changing to: --mac-bundle-identifier <ID string> An identifier that uniquely identifies the application for MacOSX Defaults to the value of --identifier option. May only use alphanumeric (A-Z,a-z,0-9), hyphen (-), and period (.) characters.
11-04-2019

2.) The --identifier Option defaults to the main class name, which makes it an appropriate default for --mac-bundle-identifier. I think we should leave this as is, with better documentation. 1.) The resulting "app.identifier" in the ".cfg" file, is used by the native code as a sub-directory of the system application data directory for location of "cache" directory related to CDS. I can't see that this is actually used, but I am reluctant to remove it at this time. 4.) The usage of "app.preferences.id" by the native code is related to functionality no longer present, and can be removed, along with other fallback code no longer used.
11-04-2019

Alexander said: ---------- 1) One of usage of --identifier, which I found is to put it into app cfg file for app.identifier. Do you know if we really need this? 2) It is used as default value for MAC_BUNDLE_IDENTIFIER (--mac-bundle-identifier), not sure if it is clear from help, so we might want to drop it as default value for mac-bundle-identifier. 3) Used as ID in pkg-ref (xml config used to build OS X installer). I did not found any other usages, so I think we might want to change "3" to use mac-bundle-identifier and probably do not use it as default value for mac-bundle-identifier. --------- I agree we should remove the fallback (2) and use mac-bundle-identifier in (3). However I am still trying to figure out if the option can be removed: (1) - as noted above it is written into the cfg file as "app.identifier" - also a modified version of it is also written to cfg file as "app.preferences.id" (replacing ('.', '/')). the native code in libapplauncher then picks this value up and launches java with "-Dapp.preferences.id <that value>" looking at javapackager in JDK9, I believe this was used for loading java.util.preferences which we no longer do.
19-03-2019