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

[forax at 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 -----
> De: "Mandy Chung" <mandy.chung at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>, "hotspot-runtime-dev" <hotspot-runtime-dev at openjdk.java.net>
> 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
> 
> > On Jun 4, 2016, at 4:10 AM, Remi Forax <forax at univ-mlv.fr> 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 ?
> > 
> > cheers,
> > Rémi
> > 
> > ----- Mail original -----
> >> De: "Mandy Chung" <mandy.chung at oracle.com>
> >> À: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>, "hotspot-runtime-dev"
> >> <hotspot-runtime-dev at openjdk.java.net>
> >> 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
> >> 
> >> 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
> >> 
> >> 
> >> 
> 
>