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

[Daniel D. Daugherty]

On 6/10/16 8:52 AM, Alan Bateman wrote:
> On 10/06/2016 15:00, Coleen Phillimore wrote:
>
>> :
>>
>> 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.
> Some of these options configure the modules that are observables, 
> others augment the readability graph or exports. So they are very 
> significant to the runtime/VM. It was an implementation choice (and I 
> think the right one) to keep most of the implementation out of libjvm.
>
> As regards using system properties then this is exactly what we are 
> trying to move away from.
>
> The complexity that is the space in `-addmods` and `-limitmods` is 
> indeed an issue.

I just re-read this...

A space in the VM option? As in '-addmods<space><mod_name>'? That's a
completely new idea for VM options processing and one that we took
great pains to avoid when '-agentlib' and '-agentpath' were added
back in the JDK1.5 timeframe.

Alan, surely you remember this from the early JSR-163 and JVM/TI days...

Dan

> I would suggest not getting too concerned about this for now because 
> it needs another pass to see whether this makes sense or not. Also 
> options such as -XaddExports and -XaddReads are candidates to rename.
>>
>> 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.
> At some point then we have to modernize. The new tools (jlink, jmod, 
> ...) are using GNU style. In the case of the `jar` tool then it 
> supports both. Jon has been looking into this issue and I expect will 
> make a proposal. I have not seen any suggestion to translate -X or -XX 
> options into GNU style.
>
> -Alan.