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 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.
