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 > On Jun 4, 2016, at 9:46 AM, fo...@univ-mlv.fr wrote: > > 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.ch...@oracle.com> >> À: "Remi Forax" <fo...@univ-mlv.fr> >> Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net>, "hotspot-runtime-dev" >> <hotspot-runtime-...@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 <fo...@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.ch...@oracle.com> >>>> À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net>, "hotspot-runtime-dev" >>>> <hotspot-runtime-...@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 >>>> >>>> >>>> >> >>
