On 10 Jun 2016, at 21:13, Daniel D. Daugherty <daniel.daughe...@oracle.com> wrote: > > 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 >
The point being that options of this style are not only not understood in earlier versions but they cause exceptions. I came across it during testing of our app with minimal changes to existing setup (passing same options to every VM version >= 1.6). There’s an easy workaround in this context (don’t pass the same options to JDK8 and JDK9), but it seemed appropriate to flag it at this point. Robert
