JDK-8219536 : Add Option for user defined jlink options
  • Type: Enhancement
  • Component: tools
  • Sub-Component: jpackage
  • Affected Version: 14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-02-21
  • Updated: 2020-06-17
  • Resolved: 2020-04-30
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.
JDK 15
15 b22Fixed
Related Reports
CSR :  
JDK-8243272 - Add jpackage option for user defined jlink options
Relates :  
JDK-8245656 - Document jpackager options for user-defined jlink options
Relates :  
JDK-8218055 - Use ToolProvider instead of AppRuntimeImageBuilder.
Relates :  
JDK-8247779 - Remove deprecated --bind-services option from jpackage
Relates :  
JDK-8233594 - create a new option --bind-services to pass on to jlink
Relates :  
JDK-8247768 - JEP 392: Packaging Tool
Description
With the implementation of JDK-8218055, jpackager calls jlink thru the tool provider when either packaging the current jre, or packaging an application using the current jre.
This may be expanded in a future release to include when using other jres, by invoking the jlink in that jre.

In any case, when invoking jlink the user should be able to specify any arbitrary jlink options.

We have one specific jpackage option, --strip-native-commands that could be removed in favor of a more general syntax to allow user to specify things like: --limit-modules, and --bind-services
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/92a601e23fbd User: herrick Date: 2020-04-30 23:30:59 +0000
30-04-2020
The new test failed on Mac due relative location of resource file in the runtime. fixed in webrev.06: http://cr.openjdk.java.net/~herrick/8219536/webrev.06
30-04-2020
updated webrev.05 (with unit test): http://cr.openjdk.java.net/~herrick/8219536/webrev.05
30-04-2020
webrev.02 does not contain: 1.) A new automated test for this option will be created. 2.) "--bind-services" will be deprecated (it's usage will cause a deprecation warning). 3.) Existing tests using "--bind-services" need be modified to accommodate the deprecation warning.
21-04-2020
--output, --add-modules, and --module-path are used in all jpackages invocation of jlink, along with the value of jlink-options. Using these options in --jlink-options will cause an error. "--strip-native-commands --strip-debug --no-man-pages --no-header-files" is the default value of jlink-options, so if --jlink-option jpackage option is used, they will not be used (unless included in the value of --jlink-option. --bind-services is then obsolete, but can still be used to add the --bind-services jlink option. webrev: http://cr.openjdk.java.net/~herrick/8219536/webrev.02
18-04-2020
What is the default jlink option javapackager pass to jlink? I would assume that app image does not want the header files and man pages retained in the runtime image. An alternative design would be: Add --compress, --strip-debug, and --bind-services option to jpackage and pass them to jlink when creating the modular runtime image. If a user wants to use any other jlink options, they can create the custom runtime image in a separate step and then pass the image to jpackage --runtime-image option.
21-02-2019
proposal: 1.) remove existing jpackage option "--strip-native-command" 2.) options "--output", "--module-path", and --add-modules (already used by jpackage) are prohibited. 3.) any other option already used by jpackage (such as --exclude-files) will be allowed and will overrule the default value. 4.) we will remove the default usage of "--strip-debug" and "--no-header-files" and only add them is user sets them with this option. 5.) finally we add the new option: --jlink-option <option name> [option value] the option name will not contain the "--", but otherwise be the long name of any jlink or jlink-plugin option. we will not try to interpret it (other tan to see if it is already used by jpackage) and pass it on to jlink. Only one jlink option is given per jpackage --jlink-option option. (Multiple jpackage "--jlink-options" can be used). example: --jlink-option limit-modules mod1,mod2 --jlink-option bind-services --link-option strip-native-commands will resilt in invoking jlink with arguments: "--limit-modules mod1,mod2 --bind-services --strip-native-commands"
21-02-2019