JDK-8160063 : Provide a means to disable a plugin via the command line
  • Type: Enhancement
  • Component: tools
  • Sub-Component: jlink
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-06-22
  • Updated: 2016-11-08
  • Resolved: 2016-11-03
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 9
9 b143Fixed
Related Reports
Relates :  
Description
There is currently no way to disable plugins that are AUTO_ENABLED. For example, suppose we want to disable the generate-jli-classes plugin so that it doesn't generate classes at link time.
Comments
I think it's better to provide a consistent mechanism to disable any plugin. Otherwise, a plugin may choose to use "none", "off", "disable" or even does not allow to be disabled (intentionally or unintentionally). I agree that SystemModuleDescriptorPlugin should not be disabled but the runtime supports without such optimization. On the other hand, I think SystemModuleDescriptorPlugin should also be hidden from the --list-plugins. At one point there was a way to hide a plugin from the --list-plugins output. Plugin::showHelp or some way a plugin can configure to hide from --list-plugins output.
14-09-2016

I attempted --disable-<plugin_name> idea as that is clean and easy to use. But, currently only two plugins are auto-enabled. 1) GenerateJLIClassesPlugin 2) SystemModuleDescriptorPlugin I think we don't want SystemModuleDescriptorPlugin to be disabled at all [ as we generate crucial optimization info like concealed packages for example). And it turns out that GenerateJLIClassesPlugin already provides facility to turn off generation: jlink --generate-jli-classes=none disables it. That is documented in that plugin's description as well [This is equivalent to Mandy's suggestion of "off"] I think it is safer to leave the decisions to plugin (1) whether user can disable or not and (2) if can be disabled how to disable and so on.
14-09-2016

Please re-open this issue if my last comment is not acceptable or if there is better suggestion.
14-09-2016

One option is to provide a jlink option to disable the named plugins. a) --disable-plugins <plugin-name>[,<plugin-name>] jlink --disable-plugins generate-jli-classes b) --disable-<plugin-name> jlink --disable-generate-jli-classes For each plugin, jlink automatically adds `--<plugin_name>[=<arguments>]` option with an optional arguments. I like (b) symmetric with the option to configure the plugin: `--<plugin_name>[=<arguments>]` `--disable-<plugin-name>` jlink can parse CLI options and invoke the plugins that are not disabled. Another alternative could be an option to the plugin e.g. jlink --generate-jli-classes=off This will rely on the plugin implementation to handle that (the arguments are currently passed to the Plugin::configure method). `off` was the option in an early jlink prototype.
14-09-2016