2016/6/10 7:00:55 -0700, coleen.phillim...@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
