On 10/06/2016 15:18, Coleen Phillimore wrote:
On 6/4/16 7:46 AM, Alan Bateman wrote:
On 04/06/2016 12:10, Remi Forax wrote:
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
do this:
javac -J-addmods -Jmodname -J-more options.
Another fun thing you can do is this:
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
