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”) Thanks, Robert
