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

[Coleen Phillimore]

On 6/10/16 10: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.

Yes, I agree, it was the right choice to keep most of the implementation 
in the jdk libraries and only expose the jvm to what it needs to know.  
The JVM doesn't need to know these options.  I assume that the JDK 
passes this information to the JVM in some other way.  Ie. the JVM 
doesn't set any values global or otherwise based on these options.

>
> As regards using system properties then this is exactly what we are 
> trying to move away from.

 From what I gather, system properties are the way things are done for 
all sorts of jdk parameterization.  If you have a comprehensive plan to 
move *everything* away from this model, the design should be reviewed.  
Having options parsed in hotspot to set system properties doesn't seem 
like the design we really want though, unless there's some better syntax 
for it.

>
> The complexity that is the space in `-addmods` and `-limitmods` is 
> indeed an issue. 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 think the (second) pass should include moving these options back to 
the launcher where they belong.  The syntax and semantics of these 
options is pretty baffling also.

You could file an RFE to clean up this code, please add me as watcher.  
 From "Task" 8136930, this is a cleanup, but this task encompasses more 
than moving options into the JVM.  I don't see how moving the options to 
the JVM resolves the issue in this bug.


>>
>> 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.

This should also be discussed in the open (or at least I haven't seen 
it).  Mixing option syntax is very confusing.  It may be "modern" but I 
would worry about compatibility and usability.   Is there a JEP for this?

Coleen

>
> -Alan.