Review Request JDK-8136930 Examine implications for custom launchers, equivalent of java -X options in particular

[Coleen Phillimore]

On 6/9/16 2:26 AM, Alan Bateman wrote:
> On 08/06/2016 23:37, Coleen Phillimore wrote:
>>
>> :
>>
>> I have to ask why Hotspot convention was violated with this new 
>> option syntax?  These options don't start with -X and the values 
>> aren't specified as : separators like the rest? Like 
>> -Xshare:{dump,auto,on,off}, etc.  Why are these different?
> I see Mandy has pointed to -agentlib, -javaagent and others which are 
> also handled by the VM.
>
> In general then distinction between so-called standard and -X options 
> has been blurred for many years. At some point we need to take a pass 
> over the new options and decide whether they should be -X or not.  -X 
> is particularly annoying when you start to translate the option names 
> GNU style.

There are 3 options that Mandy pointed to but there are 93 options we 
handle with special case in arguments.cpp and about 1240 XX options.  
The three options are an exception.  -verbose has likely been there 
since java 1.3 and -agentlib and -agentpath probably should have had -X 
but for some reason they didn't.   If the conventions are blurred that 
doesn't really justify throwing out the entire convention, or violating 
it further.

The difference between these module options and the other non-conforming 
options is that the others actually do something in the JVM.  The module 
options only set properties for the JDK.   So we have code in the JVM 
that only affects the JDK.  This breaks encapsulation between the two 
code bases and is traditionally not what you want to do in significant 
code bases like Hotspot and jdk.

This is mostly the reason that I object to these options.  They are in 
the wrong place.  They do not affect processing in the JVM so should not 
be parsed there.  There are other known mechanisms for communicating 
with the jdk that should be followed, passing -D options directly or 
using the launcher.

I don't understand the GNU style option comment.  Java option predate 
the ubiquity of gnu style option processing.   Internally, our option 
consistency has been pretty poor, which is why I need scripts to do 
everything.   I hope there's no plan to mix in gnu style options.

>
>> :
>>
>> Someone already asked this but are there tests for all these 
>> combinations of options?
> The main tests for these options, and combinations, are in 
> jdk/tests/launcher/modules.

This seems like the best place for this test given that the 
functionality should be in the launcher.

Coleen

>
> -Alan