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

[mark.reinhold at oracle.com]

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.

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