On 6/10/16 8:16 PM, mark.reinh...@oracle.com wrote:
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.
Hi Mark, Thank you for replying. Yes, I understand below.
I have to explain that my exposure to this started with the code
review. That is, working backwards from this design. So it led me to
question the design and I hope that this is something temporary until a
a better solution can be found. I agree that it's a non-trivial problem
and urgent for jdk9 adoption.
Yes, the JVM and JDK are part of a greater whole but the whole is a lot
of software that should have proper encapsulation or the whole thing
becomes very difficult to enhance and maintain. Because these options
were added to the JVM they needed to be added to a 93 clause 'if'
statement in argument processing for special cases.
I'm discussing this with the developers and hopefully we'll arrive at
some good solution.
Thanks,
Coleen
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
