Review Request JDK-8136930 Examine implications for custom launchers, equivalent of java -X options in particular

[Alan Bateman]

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