On 6/10/16 1:08 PM, Robert Gibson wrote:
On 10 Jun 2016, at 18:38, Daniel D. Daugherty <daniel.daughe...@oracle.com>
wrote:
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
Hi,
See also, for example,
https://bugs.openjdk.java.net/browse/JDK-8159136
(NPE on current JDKs on WebStart launch with VM args “-addmods java.se.ee”)
That bug is for the JDK8u train. Why is an '-addmods java.se.ee' option
being passed to JDK8u? Or is JDK8u somehow launching a JDK9 instance?
Dan
Thanks,
Robert
