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
I would suggest not getting too concerned about this for now because
it needs another pass to see whether this makes sense or not. Also
options such as -XaddExports and -XaddReads are candidates to rename.
I don't understand the GNU style option comment. Java option predate
the ubiquity of gnu style option processing. Internally, our option
consistency has been pretty poor, which is why I need scripts to do
everything. I hope there's no plan to mix in gnu style options.
At some point then we have to modernize. The new tools (jlink, jmod,
...) are using GNU style. In the case of the `jar` tool then it
supports both. Jon has been looking into this issue and I expect will
make a proposal. I have not seen any suggestion to translate -X or -XX
options into GNU style.
-Alan.
