RFR 8163256: jlink/plugins/ExcludeVMPluginTest.java failed with Selected VM server doesn't exist

[Sundararajan Athijegannathan]

Please review http://cr.openjdk.java.net/~sundar/8163256/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8163256

This is a Mac specific issue. ModuleDescriptor read from
jrt:/java.base/module-info.class resource returns osName() to be
"Darwin" - but, System.getProperty("os.name") still returns "Mac OS X".

For now, I'm fixing ExcludeVMPlugin.java to accept both. With this
change, all jlink jtreg tests pass on Mac.

Thanks,

-Sundar

Re: RFR 8163116: jlink exclude VM plugin does not fully support cross platform image creation

[Jim Laskey (Oracle)]

+1

> On Aug 4, 2016, at 10:36 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8163116/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8163116
> 
> No cross platform test added. Existing test fixed to use
> java.base/module-info.class. Also, piggybacking to fix
> FileCopierPluginTest to avoid catching PluginException.   
> 
> -Sundar
> 

Re: RFR 8163256: jlink/plugins/ExcludeVMPluginTest.java failed with Selected VM server doesn't exist

[Alan Bateman]

On 05/08/2016 01:52, Sundararajan Athijegannathan wrote:


Please review http://cr.openjdk.java.net/~sundar/8163256/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8163256

This is a Mac specific issue. ModuleDescriptor read from
jrt:/java.base/module-info.class resource returns osName() to be
"Darwin" - but, System.getProperty("os.name") still returns "Mac OS X".

For now, I'm fixing ExcludeVMPlugin.java to accept both. With this
change, all jlink jtreg tests pass on Mac.


This looks okay for now but I expect we'll need to come back to this and 
get the names aligned.


-Alan.

Review request 8136930: Simplify use of module-system options by custom launchers

[Mandy Chung]

This patch renames the module-system options to GNU-style as specified
in JEP 293 [1] (see below for the new proposed option names).  This
addresses the problems discussed in [2] that the launcher will pass 
the module-system options down to the VM in the form of =.
This provides a consistent way to configure the module system and
simplify use of module-system options by custom launcher.  This patch
also updates several JDK tools including jlink, jmod, jimage, jar,
javac, javap, javadoc, javah, jdeps such that the GNU-style 
module-system options are consistent across all tools.

Webrev:
 http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev.00/
 
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev-langtools.00/

Harold has posted a separate code review for the hotspot change [3].
webrev.00 includes changes in all repos except hotspot.  webrev-langtools.00
includes the changes in langtools repo (this may be convenient for
those who wants to review langtools change only).

Note that existing -cp and -classpath have no change and continue to
be supported.  New long form option `--class-path` and `--help` are 
added to java, javac, and other tools where applicable.

For transition, all old options except -listmods continue to be 
supported by the java launcher, javac, javadoc, javap, javah.  
I propose to remove the old options in two weeks after this patch
is promoted (i.e. two promoted builds to go through the transition).

Mandy

[1] http://openjdk.java.net/jeps/293
[2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008079.html
[3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008715.html

Existing OptionsNew Options

-addmods--add-modules
-classpath | -cp | --classpath  -classpath | -cp | --class-path
-limitmods  --limit-modules
-listmods   --list-modules
-m  --module | -m
-modulepath | -mp | --modulepath--module-path | -p
-modulesourcepath   --module-source-path
--plugin-module-path(no change)
-processormodulepath--processor-module-path
-upgrademodulepath  --upgrade-module-path
-XaddExports--add-exports
-XaddReads  --add-reads
-Xpatch --patch-module
-bootclasspath  --boot-class-path | -bootclasspath
-processorpath  --processor-path  | -processor-path
-sourcepath --source-path | -sourcepath
-system --system
-release--release

Re: RFR 8159487: Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file

[Mandy Chung]

Hi Sundar,

> On Aug 2, 2016, at 5:12 AM, Alan Bateman  wrote:
> 
> On 02/08/2016 04:39, Sundararajan Athijegannathan wrote:
> 
>> Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for
>> https://bugs.openjdk.java.net/browse/JDK-8159487
>> 
>> OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another
>> fix. Just adding "JAVA_VERSION" and a test change to check these
>> properties exist in release file.
>> 
> This seems to put the value of the "java.version" property into the release 
> file, I don't think you want that. Consider the cross targeting case where 
> jlink is running on 9 but the modules for the target image are 9.1. So it 
> needs to come from the java.base module for the target run-time image.

Alan is right. The “java.version” system property value from the jlink runtime 
is not what we want.  It needs to come from the java.base module.

In addition, make/Images.gmk needs to be updated.  These properties are no 
longer needed to be supplied by the build.

Since this patch has been pushed, I created a new JBS issue to adjust the fix:
  https://bugs.openjdk.java.net/browse/JDK-8163320

Mandy

RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs

[Steve Drach]

Hi,

Please review this changset that makes jlink multi-release jar aware.

issue: https://bugs.openjdk.java.net/browse/JDK-8156499 

webrev: http://cr.openjdk.java.net/~sdrach/8156499/webrev.00/index.html 


Thanks
Steve