Discussion:
Review Request JDK-8136930 Examine implications for custom launchers, equivalent of java -X options in particular
(too old to reply)
Mandy Chung
2016-06-04 06:47:37 UTC
Permalink
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.00/

-modulepath, -addmods, -limitmods, -XaddExports, -XaddReads, -Xpatch are java launcher options in the current implementation. Custom launchers will have to use -D to set some system properties to configure module system. Different ways to configure module system is confusing and not friendly for environments using both java launcher and custom launchers.

This patch pushes the handling of the module options into the VM. That will avoid the confusion between launcher and VM options and avoids needing to use system properties. All launcher implementations can configure the module system via JNI Invocation API setting these options in a unified way. The options and syntax remain the same as specified in JEP 261.

For the non-repeating options, like the other VM options, the last one wins. The current implementation communicates the options to the module system through system properties, as a private interface, and these system properties will be removed once they are read during the module system initialization. These system properties are reserved as private interface and they will be ignored if they are set via -D in the command line. Harold implements the hotspot change and can explain further details.

This patch will impact existing tests and scripts that set the system properties for example to break encapsulation in the command line e.g. -Djdk.launcher.addexports.<N>. They will need to be updated to replace the use of -D with the appropriate module option e.g. -XaddExports. Since they are new options in JDK 9, use -XX:+IgnoreUnrecognizedVMOptions if they need to be ignored by earlier releases.

Mandy
Alan Bateman
2016-06-04 07:05:29 UTC
Permalink
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.00/
There's an update to java.lang.System::getProperties that is missed from
the webrev, the rest of the changes in the jdk repo look fine and good
to get this done.

-Alan
Mandy Chung
2016-06-04 15:16:22 UTC
Permalink
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.00/
There's an update to java.lang.System::getProperties that is missed from the webrev, the rest of the changes in the jdk repo look fine and good to get this done.
Thanks. I updated the webrev in place to include the change in System::getProperties to reflect the rename of "jdk.upgrade.module.path" to "jdk.module.upgrade.path".

Mandy
Remi Forax
2016-06-04 11:10:36 UTC
Permalink
Hi Mandy,
did you think about using -J for specifying either VM options or module options (the user really don't care) for custom launchers like we use -J to specify VM option to javac ?

cheers,
Rémi

----- Mail original -----
Envoyé: Samedi 4 Juin 2016 08:47:37
Objet: Review Request JDK-8136930 Examine implications for custom launchers, equivalent of java -X options in
particular
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.00/
-modulepath, -addmods, -limitmods, -XaddExports, -XaddReads, -Xpatch are java
launcher options in the current implementation. Custom launchers will have
to use -D to set some system properties to configure module system.
Different ways to configure module system is confusing and not friendly for
environments using both java launcher and custom launchers.
This patch pushes the handling of the module options into the VM. That will
avoid the confusion between launcher and VM options and avoids needing to
use system properties. All launcher implementations can configure the
module system via JNI Invocation API setting these options in a unified way.
The options and syntax remain the same as specified in JEP 261.
For the non-repeating options, like the other VM options, the last one wins.
The current implementation communicates the options to the module system
through system properties, as a private interface, and these system
properties will be removed once they are read during the module system
initialization. These system properties are reserved as private interface
and they will be ignored if they are set via -D in the command line. Harold
implements the hotspot change and can explain further details.
This patch will impact existing tests and scripts that set the system
properties for example to break encapsulation in the command line e.g.
-Djdk.launcher.addexports.<N>. They will need to be updated to replace the
use of -D with the appropriate module option e.g. -XaddExports. Since they
are new options in JDK 9, use -XX:+IgnoreUnrecognizedVMOptions if they need
to be ignored by earlier releases.
Mandy
Alan Bateman
2016-06-04 11:46:12 UTC
Permalink
Post by Remi Forax
Hi Mandy,
did you think about using -J for specifying either VM options or module options (the user really don't care) for custom launchers like we use -J to specify VM option to javac ?
If "custom launcher" means the JNI innovation API then you won't be
using -J, instead you'll specify the VM options via the JavaVMInitArgs
when creating the VM .Then you'll load and invoke the entry point for
the tool, maybe specifying options to its entry/main method. To date
then creating the VM has required specifying these options via the
non-documented/internal properties so this patch addresses this.

On the other hand, if you mean launching javac or other tools, say with
ProcessBuilder, then -J should just work as it does now. Also as you
mention javac then it's important to distinguish the options for the
compilation environment from the options for the underlying runtime
environment. One could find oneself doing something doing something like
`javac -J-addmods -Jfoo -addmods bar ...` for example. It gets more fun
once you the annotation processing environment into the picture.

Just to put more context on this patch. We are cleaning up the command
line option handling and trying to get things more consistent. It will
take a number of steps. One of the patches to proceed this one is an
entry point that javac can use to pick up the runtime options. There is
also a recent javac change to pick up options from an environment
variable in a similar (but not identical) way to _JAVA_OPTIONS. Once all
the pieces are in then I think the command line option story will be
much better.

-Alan
Alan Bateman
2016-06-10 16:40:31 UTC
Permalink
Post by Alan Bateman
Post by Remi Forax
Hi Mandy,
did you think about using -J for specifying either VM options or
module options (the user really don't care) for custom launchers
like we use -J to specify VM option to javac ?
If "custom launcher" means the JNI innovation API then you won't be
using -J, instead you'll specify the VM options via the
JavaVMInitArgs when creating the VM .Then you'll load and invoke the
entry point for the tool, maybe specifying options to its entry/main
method. To date then creating the VM has required specifying these
options via the non-documented/internal properties so this patch
addresses this.
Why not just document these properties? This changeset gives them
expected names. There are other documented properties.
https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getProperties--
These properties should be documented in any case.
The proposal is to document jdk.module.path, jdk.upgrade.module.path,
jdk.module.main, and jdk.module.main.class. The @implNote is already
there but it needs an update (and is included in Mandy's patch) to
change the property that communicates the value of the upgrade module path:

http://download.java.net/java/jdk9/docs/api/java/lang/System.html#getProperties--
I was wondering this also. In order to pass -addmods to the JVM, you
javac -J-addmods -Jmodname -J-more options.
javac -J-addmods -J-XX:VMOptionsFile=x -J-moreoptions
And have the file x contain the name of the module. Intended?
What is the error message that you get when you miss out the module name?
java -addmods -XX:-UseCompressedOops ?
Does it say that the module name has been omitted or does it pass
-XX:-UseCompressedOops as a property to the jdk.
The value to -addmods is one or more modules so the next next non-SP
token will be treated as a set of modules. As touched on in other mails,
the white space in the -addmods and -limitmods options are awkward and
needs to be looked at. I expect the hardest will -modulepath and
-upgrademodulepath where it might be odd not specify a space between the
option and its value.
Of course, the -XX:+IgnoreUnrecognizedVMOptions problem is going to
require additional hacks in the jvm.
I think the main problem with be older VMs.
I think this makes it less consistent and is there an open review and
discussion about an entry point for javac to pick up the runtime
options? What would javac do with the -XX options?
If you used with -J then they will be used in the runtime environment. I
don't think javac has any -XX options for the compilation environment.

-Alan
Mandy Chung
2016-06-10 20:08:27 UTC
Permalink
Just to put more context on this patch. We are cleaning up the command line option handling and trying to get things more consistent. It will take a number of steps. One of the patches to proceed this one is an entry point that javac can use to pick up the runtime options. There is also a recent javac change to pick up options from an environment variable in a similar (but not identical) way to _JAVA_OPTIONS. Once all the pieces are in then I think the command line option story will be much better.
I think this makes it less consistent and is there an open review and discussion about an entry point for javac to pick up the runtime options? What would javac do with the -XX options?
It’s an open issue:
https://bugs.openjdk.java.net/browse/JDK-8156998

The JBS issue about the CLI option consistency and related to GNU-style
https://bugs.openjdk.java.net/browse/JDK-8152218

There are multiple ways to take argfiles that should also be examined:
https://bugs.openjdk.java.net/browse/JDK-8158076

Mandy
Mandy Chung
2016-06-04 15:31:02 UTC
Permalink
As Alan replied, custom launchers create a VM using the JNI invocation API specifying the VM options properly and no need to set -J. -J is a way JDK launchers to pass options to the runtime environment.

Mandy
Post by Remi Forax
Hi Mandy,
did you think about using -J for specifying either VM options or module options (the user really don't care) for custom launchers like we use -J to specify VM option to javac ?
cheers,
Rémi
----- Mail original -----
Envoyé: Samedi 4 Juin 2016 08:47:37
Objet: Review Request JDK-8136930 Examine implications for custom launchers, equivalent of java -X options in
particular
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.00/
-modulepath, -addmods, -limitmods, -XaddExports, -XaddReads, -Xpatch are java
launcher options in the current implementation. Custom launchers will have
to use -D to set some system properties to configure module system.
Different ways to configure module system is confusing and not friendly for
environments using both java launcher and custom launchers.
This patch pushes the handling of the module options into the VM. That will
avoid the confusion between launcher and VM options and avoids needing to
use system properties. All launcher implementations can configure the
module system via JNI Invocation API setting these options in a unified way.
The options and syntax remain the same as specified in JEP 261.
For the non-repeating options, like the other VM options, the last one wins.
The current implementation communicates the options to the module system
through system properties, as a private interface, and these system
properties will be removed once they are read during the module system
initialization. These system properties are reserved as private interface
and they will be ignored if they are set via -D in the command line. Harold
implements the hotspot change and can explain further details.
This patch will impact existing tests and scripts that set the system
properties for example to break encapsulation in the command line e.g.
-Djdk.launcher.addexports.<N>. They will need to be updated to replace the
use of -D with the appropriate module option e.g. -XaddExports. Since they
are new options in JDK 9, use -XX:+IgnoreUnrecognizedVMOptions if they need
to be ignored by earlier releases.
Mandy
f***@univ-mlv.fr
2016-06-04 16:46:20 UTC
Permalink
Hi Alan, hi Mandy,
thanks for your answers,
by 'custom launcher', i was thinking about the launchers created by jlink, this one need a -J like option, not a JNI invoked piece of C.

cheers,
Rémi

----- Mail original -----
Envoyé: Samedi 4 Juin 2016 17:31:02
Objet: Re: Review Request JDK-8136930 Examine implications for custom launchers, equivalent of java -X options in
particular
As Alan replied, custom launchers create a VM using the JNI invocation API
specifying the VM options properly and no need to set -J. -J is a way JDK
launchers to pass options to the runtime environment.
Mandy
Post by Remi Forax
Hi Mandy,
did you think about using -J for specifying either VM options or module
options (the user really don't care) for custom launchers like we use -J
to specify VM option to javac ?
cheers,
Rémi
----- Mail original -----
Envoyé: Samedi 4 Juin 2016 08:47:37
Objet: Review Request JDK-8136930 Examine implications for custom
launchers, equivalent of java -X options in
particular
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.00/
-modulepath, -addmods, -limitmods, -XaddExports, -XaddReads, -Xpatch are java
launcher options in the current implementation. Custom launchers will have
to use -D to set some system properties to configure module system.
Different ways to configure module system is confusing and not friendly for
environments using both java launcher and custom launchers.
This patch pushes the handling of the module options into the VM. That will
avoid the confusion between launcher and VM options and avoids needing to
use system properties. All launcher implementations can configure the
module system via JNI Invocation API setting these options in a unified way.
The options and syntax remain the same as specified in JEP 261.
For the non-repeating options, like the other VM options, the last one wins.
The current implementation communicates the options to the module system
through system properties, as a private interface, and these system
properties will be removed once they are read during the module system
initialization. These system properties are reserved as private interface
and they will be ignored if they are set via -D in the command line. Harold
implements the hotspot change and can explain further details.
This patch will impact existing tests and scripts that set the system
properties for example to break encapsulation in the command line e.g.
-Djdk.launcher.addexports.<N>. They will need to be updated to replace the
use of -D with the appropriate module option e.g. -XaddExports. Since they
are new options in JDK 9, use -XX:+IgnoreUnrecognizedVMOptions if they need
to be ignored by earlier releases.
Mandy
Mandy Chung
2016-06-04 18:43:41 UTC
Permalink
I see your point. jlink currently creates a script that calls the java launcher to run a module with main class. None of the module options is needed in launching a modular app that is linked in the image. -J option or like would be needed when the user wants to alter the startup option in launching such modular app. This ability should be considered when jlink creates a custom launcher in the future.

Mandy
Post by f***@univ-mlv.fr
Hi Alan, hi Mandy,
thanks for your answers,
by 'custom launcher', i was thinking about the launchers created by jlink, this one need a -J like option, not a JNI invoked piece of C.
cheers,
Rémi
----- Mail original -----
Envoyé: Samedi 4 Juin 2016 17:31:02
Objet: Re: Review Request JDK-8136930 Examine implications for custom launchers, equivalent of java -X options in
particular
As Alan replied, custom launchers create a VM using the JNI invocation API
specifying the VM options properly and no need to set -J. -J is a way JDK
launchers to pass options to the runtime environment.
Mandy
Post by Remi Forax
Hi Mandy,
did you think about using -J for specifying either VM options or module
options (the user really don't care) for custom launchers like we use -J
to specify VM option to javac ?
cheers,
Rémi
----- Mail original -----
Envoyé: Samedi 4 Juin 2016 08:47:37
Objet: Review Request JDK-8136930 Examine implications for custom
launchers, equivalent of java -X options in
particular
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.00/
-modulepath, -addmods, -limitmods, -XaddExports, -XaddReads, -Xpatch are java
launcher options in the current implementation. Custom launchers will have
to use -D to set some system properties to configure module system.
Different ways to configure module system is confusing and not friendly for
environments using both java launcher and custom launchers.
This patch pushes the handling of the module options into the VM. That will
avoid the confusion between launcher and VM options and avoids needing to
use system properties. All launcher implementations can configure the
module system via JNI Invocation API setting these options in a unified way.
The options and syntax remain the same as specified in JEP 261.
For the non-repeating options, like the other VM options, the last one wins.
The current implementation communicates the options to the module system
through system properties, as a private interface, and these system
properties will be removed once they are read during the module system
initialization. These system properties are reserved as private interface
and they will be ignored if they are set via -D in the command line. Harold
implements the hotspot change and can explain further details.
This patch will impact existing tests and scripts that set the system
properties for example to break encapsulation in the command line e.g.
-Djdk.launcher.addexports.<N>. They will need to be updated to replace the
use of -D with the appropriate module option e.g. -XaddExports. Since they
are new options in JDK 9, use -XX:+IgnoreUnrecognizedVMOptions if they need
to be ignored by earlier releases.
Mandy
David Holmes
2016-06-06 00:50:45 UTC
Permalink
Hi Mandy,
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.00/
-modulepath, -addmods, -limitmods, -XaddExports, -XaddReads, -Xpatch are java launcher options in the current implementation. Custom launchers will have to use -D to set some system properties to configure module system. Different ways to configure module system is confusing and not friendly for environments using both java launcher and custom launchers.
This patch pushes the handling of the module options into the VM. That will avoid the confusion between launcher and VM options and avoids needing to use system properties. All launcher implementations can configure the module system via JNI Invocation API setting these options in a unified way. The options and syntax remain the same as specified in JEP 261.
For the non-repeating options, like the other VM options, the last one wins. The current implementation communicates the options to the module system through system properties, as a private interface, and these system properties will be removed once they are read during the module system initialization. These system properties are reserved as private interface and they will be ignored if they are set via -D in the command line. Harold implements the hotspot change and can explain further details.
This patch will impact existing tests and scripts that set the system properties for example to break encapsulation in the command line e.g. -Djdk.launcher.addexports.<N>. They will need to be updated to replace the use of -D with the appropriate module option e.g. -XaddExports. Since they are new options in JDK 9, use -XX:+IgnoreUnrecognizedVMOptions if they need to be ignored by earlier releases.
Taking an initial look at the VM changes ...

I may be missing the full context but you seem to be checking only that
some prefix matches the expected property format, not that the entire
value is valid eg. if passed jdk.module.patch.1junk it will match

You use NEW_C_HEAP_ARRAY in places but that will abort the VM on
failure, whereas you return error codes for other failure modes. For
consistency use NEW_C_HEAP_ARRAY_RETURN_NULL and return an error on
NULL. (This seems a pre-existing flaw.)

There seem to be far too many string literals for the various
jdk.module.* forms and lots of hard-coded string lengths. It would be
nice if that could be cleaned up using #defines, or string constant
variables, so that all the potential property names can be located in
one place.

Are there any tests in hotspot/test/* that will require changes for this?

Thanks,
David
Post by Mandy Chung
Mandy
Mandy Chung
2016-06-06 03:51:28 UTC
Permalink
Post by David Holmes
Taking an initial look at the VM changes ...
I may be missing the full context but you seem to be checking only that some prefix matches the expected property format, not that the entire value is valid eg. if passed jdk.module.patch.1junk it will match
-Djdk.module.patch.1junk=<arg> is expected not match and should not be ignored. Hence it should be set in the system property.

155 ((strncmp(prop_end, "patch.", 6) == 0) && isdigit(prop_end[6]))) {

Harold - is it intentional? I assume we want to match the suffix if it’s a number.
Post by David Holmes
You use NEW_C_HEAP_ARRAY in places but that will abort the VM on failure, whereas you return error codes for other failure modes. For consistency use NEW_C_HEAP_ARRAY_RETURN_NULL and return an error on NULL. (This seems a pre-existing flaw.)
There seem to be far too many string literals for the various jdk.module.* forms and lots of hard-coded string lengths. It would be nice if that could be cleaned up using #defines, or string constant variables, so that all the potential property names can be located in one place.
I agree.
Post by David Holmes
Are there any tests in hotspot/test/* that will require changes for this?
Not in the hotspot open repo.

Mandy
Mandy Chung
2016-06-08 16:35:06 UTC
Permalink
Updated webrev with Harold’s latest VM change incorporating the review comments:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.01/index.html

Harold - the revised VM change looks okay to me.

Minor one: you define the following:
202 #define MODULE_PATH_PROPERTY "-Djdk.module.path”
204 #define MODULE_UPGRADE_PATH_PROPERTY "-Djdk.module.upgrade.path"

It may be good to consider having #define for all module property names and used consistently.

Mandy
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.00/
-modulepath, -addmods, -limitmods, -XaddExports, -XaddReads, -Xpatch are java launcher options in the current implementation. Custom launchers will have to use -D to set some system properties to configure module system. Different ways to configure module system is confusing and not friendly for environments using both java launcher and custom launchers.
This patch pushes the handling of the module options into the VM. That will avoid the confusion between launcher and VM options and avoids needing to use system properties. All launcher implementations can configure the module system via JNI Invocation API setting these options in a unified way. The options and syntax remain the same as specified in JEP 261.
For the non-repeating options, like the other VM options, the last one wins. The current implementation communicates the options to the module system through system properties, as a private interface, and these system properties will be removed once they are read during the module system initialization. These system properties are reserved as private interface and they will be ignored if they are set via -D in the command line. Harold implements the hotspot change and can explain further details.
This patch will impact existing tests and scripts that set the system properties for example to break encapsulation in the command line e.g. -Djdk.launcher.addexports.<N>. They will need to be updated to replace the use of -D with the appropriate module option e.g. -XaddExports. Since they are new options in JDK 9, use -XX:+IgnoreUnrecognizedVMOptions if they need to be ignored by earlier releases.
Mandy
harold seigel
2016-06-08 17:22:36 UTC
Permalink
Hi Mandy,

Yes, I can make that change. Thanks for pointing it out.

Harold
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.01/index.html
Harold - the revised VM change looks okay to me.
202 #define MODULE_PATH_PROPERTY "-Djdk.module.path”
204 #define MODULE_UPGRADE_PATH_PROPERTY "-Djdk.module.upgrade.path"
It may be good to consider having #define for all module property names and used consistently.
Mandy
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.00/
-modulepath, -addmods, -limitmods, -XaddExports, -XaddReads, -Xpatch are java launcher options in the current implementation. Custom launchers will have to use -D to set some system properties to configure module system. Different ways to configure module system is confusing and not friendly for environments using both java launcher and custom launchers.
This patch pushes the handling of the module options into the VM. That will avoid the confusion between launcher and VM options and avoids needing to use system properties. All launcher implementations can configure the module system via JNI Invocation API setting these options in a unified way. The options and syntax remain the same as specified in JEP 261.
For the non-repeating options, like the other VM options, the last one wins. The current implementation communicates the options to the module system through system properties, as a private interface, and these system properties will be removed once they are read during the module system initialization. These system properties are reserved as private interface and they will be ignored if they are set via -D in the command line. Harold implements the hotspot change and can explain further details.
This patch will impact existing tests and scripts that set the system properties for example to break encapsulation in the command line e.g. -Djdk.launcher.addexports.<N>. They will need to be updated to replace the use of -D with the appropriate module option e.g. -XaddExports. Since they are new options in JDK 9, use -XX:+IgnoreUnrecognizedVMOptions if they need to be ignored by earlier releases.
Mandy
Mandy Chung
2016-06-08 17:58:36 UTC
Permalink
Hello Mandy,
As I understand all these options are tested by following tests: jdk/test/tools/launcher/modules. I.e. no additional tests are required for moving these options to the VM(except 2 new tests)?
Correct. The options and syntax remain the same as it’s specified in JEP 261. The existing tests cover these options.
RuntimeArguments.java - to check that these options are VM options
IgnoreModulePropertiesTest.java - to check that java throws an exception for invalid values and that corresponding properties are ignored.
38 // Test that the specified property and its value are ignored. If the VM accepted
39 // the property and value then an exception would be thrown because the value is
40 // bogus for that property. But, since the property is ignored no exception is
41 // thrown.
42 public static void testProperty(String prop, String value) throws Exception {
43 ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(
44 "-D" + prop + "=" + value, "-version");
45 OutputAnalyzer output = new OutputAnalyzer(pb.start());
46 output.shouldContain("java version ");
47 output.shouldHaveExitValue(0);
48
49 // Ensure that the property and its value aren't available.
50 if (System.getProperty(prop) != null) {
51 throw new RuntimeException(
52 "Unexpected non-null value for property " + prop);
53 }
54 }
Lines 49-53 verifies that property not exist, but this property is obtained from the main test and not from the launched vm(launched with "-D" + prop + "=" + value). Is it intended?
This is to check the property set in the main test and not the properties and options passed to testWhiteSpaceOption and testOption metohds since the argument is invalid.

The main test itself only sets -XaddExports. It could have @run to specify -addmods and -limitmods with a valid argument to cover a couple of other properties. The main thing for this test to validate is that -D is dropped.

Mandy
Mandy Chung
2016-06-08 23:42:04 UTC
Permalink
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.01/jdk/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java.udiff.html
+ /**
+ * Gets and remove the named system property
+ */
+ private static String getAndRemoveProperty(String key) {
+ return (String)System.getProperties().remove(key);
+ }
There are two of these. Should there be only one in the System class?
This is private. If it’s moved to System, it would need a shared secret to access it that is overkill for this simple call.

Mandy
Coleen Phillimore
2016-06-10 20:01:22 UTC
Permalink
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.01/jdk/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java.udiff.html
+ /**
+ * Gets and remove the named system property
+ */
+ private static String getAndRemoveProperty(String key) {
+ return (String)System.getProperties().remove(key);
+ }
There are two of these. Should there be only one in the System class?
This is private. If it’s moved to System, it would need a shared secret to access it that is overkill for this simple call.
Ok.
Coleen
Post by Mandy Chung
Mandy
Mandy Chung
2016-06-09 00:45:11 UTC
Permalink
Adding jigsaw-dev where the code review is posted. See [1] for Coleen’s review comment.
I have to ask why Hotspot convention was violated with this new option
syntax? These options don't start with -X and the values aren't
specified as : separators like the rest? Like
-Xshare:{dump,auto,on,off}, etc. Why are these different?
Good question. Presumably these are not non-standard arguments, but common arguments that must always be supported, hence not -X. But this somewhat muddies the waters as the VM itself has, to my recollection, never had standard arguments: VM arguments are -XX arguments, other arguments were launcher arguments. So yes this seems to be introducing a new kind of VM argument.
-agentlib, -agentpath, -javaagent, -verbose:{gc,class,jni} are neither -X nor -XX options.
This also begs the questions as to where you get help for these options once moved into the JVM? Will the launcher be updated to pretend they are launcher arguments and document them?
Good question on the documentation. java -help continues to print these module options as -verbose:gc option is shown and I don’t see any issue for java help message and its documentation to list VM options.

I think they should be listed in the HotSpot VM options documentation:
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

Mandy
[1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-June/019882.html
David Holmes
2016-06-09 06:44:34 UTC
Permalink
Hi Mandy,
Post by Mandy Chung
Adding jigsaw-dev where the code review is posted. See [1] for Coleen’s review comment.
I have to ask why Hotspot convention was violated with this new option
syntax? These options don't start with -X and the values aren't
specified as : separators like the rest? Like
-Xshare:{dump,auto,on,off}, etc. Why are these different?
Good question. Presumably these are not non-standard arguments, but common arguments that must always be supported, hence not -X. But this somewhat muddies the waters as the VM itself has, to my recollection, never had standard arguments: VM arguments are -XX arguments, other arguments were launcher arguments. So yes this seems to be introducing a new kind of VM argument.
-agentlib, -agentpath, -javaagent, -verbose:{gc,class,jni} are neither -X nor -XX options.
Mea culpa - yes we already have these kind of options. Thanks.
Post by Mandy Chung
This also begs the questions as to where you get help for these options once moved into the JVM? Will the launcher be updated to pretend they are launcher arguments and document them?
Good question on the documentation. java -help continues to print these module options as -verbose:gc option is shown and I don’t see any issue for java help message and its documentation to list VM options.
Ok.
Post by Mandy Chung
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
Note that documentation currently states:

"Standard options recognized by the Java HotSpot VM are described on the
Java Application Launcher reference pages for Windows and Solaris &
Linux. This document deals exclusively with non-standard options
recognized by the Java HotSpot VM."

but I tend to agree that it should also list all options that are not
launcher options. There should also be a cross-reference from the JNI
invocation API documentation to whereever these options are documented.

Thanks,
David
-----
Post by Mandy Chung
Mandy
[1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-June/019882.html
Alan Bateman
2016-06-09 06:26:36 UTC
Permalink
I have to ask why Hotspot convention was violated with this new option
syntax? These options don't start with -X and the values aren't
specified as : separators like the rest? Like
-Xshare:{dump,auto,on,off}, etc. Why are these different?
I see Mandy has pointed to -agentlib, -javaagent and others which are
also handled by the VM.

In general then distinction between so-called standard and -X options
has been blurred for many years. At some point we need to take a pass
over the new options and decide whether they should be -X or not. -X is
particularly annoying when you start to translate the option names GNU
style.
Someone already asked this but are there tests for all these
combinations of options?
The main tests for these options, and combinations, are in
jdk/tests/launcher/modules.

-Alan
Coleen Phillimore
2016-06-10 14:00:55 UTC
Permalink
Post by Alan Bateman
I have to ask why Hotspot convention was violated with this new
option syntax? These options don't start with -X and the values
aren't specified as : separators like the rest? Like
-Xshare:{dump,auto,on,off}, etc. Why are these different?
I see Mandy has pointed to -agentlib, -javaagent and others which are
also handled by the VM.
In general then distinction between so-called standard and -X options
has been blurred for many years. At some point we need to take a pass
over the new options and decide whether they should be -X or not. -X
is particularly annoying when you start to translate the option names
GNU style.
There are 3 options that Mandy pointed to but there are 93 options we
handle with special case in arguments.cpp and about 1240 XX options.
The three options are an exception. -verbose has likely been there
since java 1.3 and -agentlib and -agentpath probably should have had -X
but for some reason they didn't. If the conventions are blurred that
doesn't really justify throwing out the entire convention, or violating
it further.

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 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.
Post by Alan Bateman
Someone already asked this but are there tests for all these
combinations of options?
The main tests for these options, and combinations, are in
jdk/tests/launcher/modules.
This seems like the best place for this test given that the
functionality should be in the launcher.

Coleen
Post by Alan Bateman
-Alan
Alan Bateman
2016-06-10 14:52:48 UTC
Permalink
Post by Coleen Phillimore
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.
Post by Coleen Phillimore
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.
Daniel D. Daugherty
2016-06-10 16:38:03 UTC
Permalink
Post by Alan Bateman
Post by Coleen Phillimore
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
Post by Alan Bateman
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.
Post by Coleen Phillimore
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.
Robert Gibson
2016-06-10 19:08:07 UTC
Permalink
Post by Daniel D. Daugherty
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”)

Thanks,
Robert
Daniel D. Daugherty
2016-06-10 19:13:51 UTC
Permalink
Post by Robert Gibson
Post by Daniel D. Daugherty
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
Post by Robert Gibson
Thanks,
Robert
Robert Gibson
2016-06-10 19:45:50 UTC
Permalink
Post by Daniel D. Daugherty
Post by Robert Gibson
Post by Daniel D. Daugherty
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
Alan Bateman
2016-06-10 19:53:28 UTC
Permalink
Post by Daniel D. Daugherty
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...
The main effort here is to move these options down to the VM and avoid a
repeat of the past where non-`java` launchers used different options or
properties compared to the launcher. Whether the code that directly acts
on the options is in libjvm or in java code is just implementation
detail (and could change over time).

The white spec issue is messy but that needs to be part of a separate
effort to sort out the new option names and syntax. Jon has been looking
into this.

-Alan.
Mandy Chung
2016-06-10 19:56:32 UTC
Permalink
Post by Daniel D. Daugherty
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...
The main effort here is to move these options down to the VM and avoid a repeat of the past where non-`java` launchers used different options or properties compared to the launcher. Whether the code that directly acts on the options is in libjvm or in java code is just implementation detail (and could change over time).
The white spec issue is messy but that needs to be part of a separate effort to sort out the new option names and syntax. Jon has been looking into this.
See https://bugs.openjdk.java.net/browse/JDK-8152218

Mandy
Alan Bateman
2016-06-10 20:21:45 UTC
Permalink
Yes, I agree, it was the right choice to keep most of the
implementation in the jdk libraries and only expose the jvm to what it
needs to know. The JVM doesn't need to know these options. I assume
that the JDK passes this information to the JVM in some other way.
Ie. the JVM doesn't set any values global or otherwise based on these
options.
-Xpatch has to processed very early (before any classes are loaded). The
other module options are also processed very early in the startup but by
java code that configures the VM rather than by code in libjvm. If you
run with -Xlog:modules=debug then you'll see the initialization.
From what I gather, system properties are the way things are done for
all sorts of jdk parameterization. If you have a comprehensive plan
to move *everything* away from this model, the design should be
reviewed. Having options parsed in hotspot to set system properties
doesn't seem like the design we really want though, unless there's
some better syntax for it.
System properties have been historically used to communicate the value
of options but it doesn't have to be this way and we'd like to get away
from that over time. We can't of course change existing properties (like
java.class.path) for example.
I think the (second) pass should include moving these options back to
the launcher where they belong. The syntax and semantics of these
options is pretty baffling also.
The java launcher is not involved when you use the JNI invocation API.

On the syntax/semantics of these options then JEP 261 has all the
details. Yes, a lot to take in at once.

-Alan.
Coleen Phillimore
2016-06-10 20:56:33 UTC
Permalink
Post by Alan Bateman
Yes, I agree, it was the right choice to keep most of the
implementation in the jdk libraries and only expose the jvm to what
it needs to know. The JVM doesn't need to know these options. I
assume that the JDK passes this information to the JVM in some other
way. Ie. the JVM doesn't set any values global or otherwise based on
these options.
-Xpatch has to processed very early (before any classes are loaded).
The other module options are also processed very early in the startup
but by java code that configures the VM rather than by code in libjvm.
If you run with -Xlog:modules=debug then you'll see the initialization.
I agree -Xpatch needs to be in the vm. It is used by the vm.
Post by Alan Bateman
From what I gather, system properties are the way things are done for
all sorts of jdk parameterization. If you have a comprehensive plan
to move *everything* away from this model, the design should be
reviewed. Having options parsed in hotspot to set system properties
doesn't seem like the design we really want though, unless there's
some better syntax for it.
System properties have been historically used to communicate the value
of options but it doesn't have to be this way and we'd like to get
away from that over time. We can't of course change existing
properties (like java.class.path) for example.
Changing the conventions for a couple things but not all does not
simplify anything. And you're not really changing the communication
between the world and the jdk. They're still properties.
Post by Alan Bateman
I think the (second) pass should include moving these options back to
the launcher where they belong. The syntax and semantics of these
options is pretty baffling also.
The java launcher is not involved when you use the JNI invocation API.
True.
Post by Alan Bateman
On the syntax/semantics of these options then JEP 261 has all the
details. Yes, a lot to take in at once.
Yeah, there's a lot here.

Coleen
Post by Alan Bateman
-Alan.
m***@oracle.com
2016-06-11 00:16:06 UTC
Permalink
Post by Coleen Phillimore
...
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
Coleen Phillimore
2016-06-13 12:13:20 UTC
Permalink
Post by m***@oracle.com
Post by Coleen Phillimore
...
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
Post by m***@oracle.com
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
m***@oracle.com
2016-06-15 22:03:47 UTC
Permalink
Post by Coleen Phillimore
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.
Glad to hear it. Thanks for your understanding.

- Mark

Mandy Chung
2016-06-10 15:31:34 UTC
Permalink
Harold has incorporated feedback from David, Coleen, Lois and others and updated webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.02/

The only change compared to webrev.01 is in hotspot arguments.{cpp,hpp} and a new ModuleOptionsTest.java.

I see concerns from Coleen on the option name and syntax. I’d like to separate that discussion from this fix and follow up after this push unless any objection.

Mandy
Daniel D. Daugherty
2016-06-10 16:33:24 UTC
Permalink
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.02/
The only change compared to webrev.01 is in hotspot arguments.{cpp,hpp} and a new ModuleOptionsTest.java.
I see concerns from Coleen on the option name and syntax. I’d like to separate that discussion from this fix and follow up after this push unless any objection.
Hmmmm... My reading of Coleen's comments is that she is objecting to adding
these new options to the JVM. Her concerns are _not_ just on the option
name and syntax. Please do not push this until Coleen is satisfied with
the resolution to her objections.

Dan
Post by Mandy Chung
Mandy
Loading...