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

[Coleen Phillimore]

On 6/10/16 8:16 PM, mark.reinhold at oracle.com wrote:
> 2016/6/10 7:00:55 -0700, coleen.phillimore at oracle.com:
>> ...
>>
>> 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 agree that, in general, we want to maintain a clean and tight interface
> between the VM and the run-time libraries.  They are not, however,
> separate systems, but parts of a greater whole.  Neither stands alone.

Hi Mark,  Thank you for replying.  Yes, I understand below.

I have to explain that my exposure to this started with the code 
review.  That is, working backwards from this design.   So it led me to 
question the design and I hope that this is something temporary until a 
a better solution can be found.  I agree that it's a non-trivial problem 
and urgent for jdk9 adoption.

Yes, the JVM and JDK are part of a greater whole but the whole is a lot 
of software that should have proper encapsulation or the whole thing 
becomes very difficult to enhance and maintain.   Because these options 
were added to the JVM they needed to be added to a 93 clause 'if' 
statement in argument processing for special cases.

I'm discussing this with the developers and hopefully we'll arrive at 
some good solution.

Thanks,
Coleen
>
> The run-time environment can be launched in two different ways, via the
> traditional `java` command-line launcher (which happens to be defined
> outside of the VM repo) and via the JNI invocation API (which happens to
> be defined in the VM repo).  Developers and customers use the latter to
> create their own custom launchers.  From their perspective, regardless of
> which interface they use, it matters not one bit which subcomponent of
> the JDK handles their run-time options.
>
> At present, if a user is trying to get an existing system working, and
> needs to break module encapsulation in order to do so, they have to do it
> one way for the command-line launcher and in a completely different way
> for custom launchers.  This is painful, especially when dozens of options
> are needed.  That's why we're trying to provide a single way to do this,
> one that will be easily usable on the command line (the common case) and
> also usable with custom launchers.
>
> Yes, we could force the use of system properties to specify module-system
> options in both interfaces, at the cost of making the CLI (remember, the
> common case) unusable.  So we instead propose the route of using a single
> set of carefully-designed options in both interfaces.  Yes, this makes
> some of the VM code a bit more complex, but we think it's a worthwhile
> tradeoff since it will make life significantly easier for desperate
> developers trying valiantly to migrate complex systems with loads of
> internal dependencies.
>
> Should we try to clean up our options story in the longer term?
> Absolutely, and as Alan indicated Jon has done some initial thinking
> about this, which may or may not be proposed for JDK 9.  I think that's
> a separate effort, however, rather than one that should block the current
> proposal.
>
> - Mark