> On 15 Sep 2016, at 09:06, Mandy Chung <mandy.ch...@oracle.com> wrote: > > >> On Sep 15, 2016, at 8:26 AM, Alan Bateman <alan.bate...@oracle.com> wrote: >> >> On 15/09/2016 07:31, Sundararajan Athijegannathan wrote: >> >>> Please review http://cr.openjdk.java.net/~sundar/8160063/webrev.01/ for >>> https://bugs.openjdk.java.net/browse/JDK-8160063 >>> >>> * Adding --disable-<plugin_name> option for any plugin that is auto-enabled. >>> >> Should this be --disable-plugin <plugin-name> rather than synthesizing an >> option? >> > > jlink --disable-plugin generate-jli-classes does read better. The option is > more obvious. > > The other way to look at this option is an option provided by each plugin > like --generate-jli-classes=none. > > Given that the plugin name is arbitrary, "--disable-plugin <plugin-name>” > would be more obvious and I have no issue to go with that. >
Yes, that is better. I am guessing the "-disable-<plugin_name>” approach was proposed to be consistent with the plugin configuration options, so perhaps that should also be reconsidered? Paul. > >> Also would I be correct to say anarchy such as `jlink >> --disable-generate-jli-classes --generate-jli-classes` would actually run >> the plugin? Related is whether it's warning or fatal when an unknown plugin >> is specified. > > Good question. --disable-generate-jli-classes removes the plugin from the > map and so it won’t run. When an unknown plugin is specified, I suggest it > should be fatal and I think that’s the current behavior. > > If both the option to disable and to enable are specified (in any order), > fatal would be helpful such that the user is prompted to ask one thing not > the other. > > Mandy >
