Re: Review request: 8157068 ExceptionInInitializerError if images build patched to use exploded version of java.lang.module.SystemModules

[Mandy Chung]

> On May 19, 2016, at 9:19 AM, Alan Bateman  wrote:
> 
> 
> On 19/05/2016 15:48, Mandy Chung wrote:
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.01/index.html
>> 
>> Mandy
>> 
> This looks okay except the naming of the sub-directories (basic and 
> SystemModules) is inconsistent. Maybe it needs to be 
> systemmodules/PatchSystemModules.java.

I’m okay to rename them.

Mandy

Re: Review request: 8157068 ExceptionInInitializerError if images build patched to use exploded version of java.lang.module.SystemModules

[Alan Bateman]

On 19/05/2016 15:48, Mandy Chung wrote:

Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.01/index.html

Mandy

This looks okay except the naming of the sub-directories (basic and 
SystemModules) is inconsistent. Maybe it needs to be 
systemmodules/PatchSystemModules.java.


-Alan.

Re: Review request: 8157068 ExceptionInInitializerError if images build patched to use exploded version of java.lang.module.SystemModules

[Mandy Chung]

Updated webrev:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.01/index.html

Mandy

Re: Fwd: Re: Modules with packages duplication

[Georgiy Rakov]

Attempt to attach zip failed. Attaching the same content as a patch 
files.diff. It can be "extracted" by invoking:


   hg init

   hg import files.diff -m comments

On 18.05.2016 18:16, Jonathan Gibbons wrote:
Without yet looking at your zip file, it is possible to compile 
classes that will not load in the application class loader, because of 
the restrictions defined for the boot layer. That does not imply the 
classes themselves are invalid, since they can be loaded and run in 
suitable configured layers/classloaders.


-- Jon


On 05/18/2016 05:53 AM, Georgiy Rakov wrote:


Hello Jon,

we've encountered situation when class files resulted from successful 
compilation cause runtime error; the sources are compiled by single 
javac invocation. This looks like incorrect javac behavior, namely it 
seems that javac should produce compile-time error if one tries to 
compile sources which will cause error at runtime. Could you please 
confirm if it's really is.


More details are provided in the forwarded message below. I have also 
attached an archive with minimized testcase and scripts to run it. In 
order to run it please:


1. Unzip attached archive to some machine (Windows or Unix);

2. If it's Windows rename test18/test_bat to test18/test.bat.

3. Modify JDK_HOME variable inside test18/test.bat (or 
test18/test.sh) to point to your JDK installation.


4. Run test18/test.bat (or test18/test.sh).

Thank you,

Georgiy.



 Forwarded Message 
Subject:Re: Modules with packages duplication
Date:   Thu, 05 May 2016 18:21:20 +0300
From:   Konstantin Barzilovich 
Organization:   Oracle Corporation
To: 	ML OpenJDK Jigsaw Developers , Alan 
Bateman 




Hello Alan,

Thank you for the answer.

I have one more question connected with duplication of packages.
Now we can compile two modules with the duplicated package without compile-time 
error if there is no module which can access both of them.
But in case of these two modules are readable by third module, in runtime it 
will result in error of boot Layer, as you said.
Is it okey, that compiler allow us to compile code, that will cause runtime 
failure?

Here is minimal test case:
--
module1/module-info.java
module module1 {
  exports pack;
}

module1/pack/A.java:
package pack;
public class A{}

module2/module-info.java
module module2 {
}

module2/pack/A.java:
package pack;
public class A{}

module3/module-info.java:
module module3{
  requires module1;
  requires module2;
}

Thanks,
Konstantin.

>
> On 04/05/2016 14:18, Konstantin Barzilovich wrote:
>> Hello,
>>
>> I can see that RI checks if there are packages with the same names in >> 
different modules (named or unnamed).
>> This check fails even if there is no clash (no module can read both >> 
packages).
>> Will it be the same in final version of JDK9 or it can be changed soon?
>>
> I think you are asking about modules on the application module path > (`java -modulepath ...`) 
that are resolved at startup. These are defined > to the application class loader so they cannot have 
overlapping > packages. It's trivial to do things like map each module in its own > class loader but 
that messes with visibility with lots of implications > (particularly when running with both a class 
path and module path or > where you bringing automatic modules into the picture). So what you are > 
seeing is specific to the boot Layer and no specific short term plans to > change this.
>
> -Alan




diff -r  -r 73c08b4cf501 module1/module-info.java
--- /dev/null
+++ b/module1/module-info.java
@@ -0,0 +1,3 @@
+module module1 {
+exports pack;
+}
diff -r  -r 73c08b4cf501 module1/pack/A.java
--- /dev/null
+++ b/module1/pack/A.java
@@ -0,0 +1,3 @@
+package pack;
+
+public class A{}
diff -r  -r 73c08b4cf501 module2/module-info.java
--- /dev/null
+++ b/module2/module-info.java
@@ -0,0 +1,2 @@
+module module2 {
+}
diff -r  -r 73c08b4cf501 module2/pack/A.java
--- /dev/null
+++ b/module2/pack/A.java
@@ -0,0 +1,3 @@
+package pack;
+
+public class A{}
diff -r  -r 73c08b4cf501 module3/mainpack/Main.java
--- /dev/null
+++ b/module3/mainpack/Main.java
@@ -0,0 +1,7 @@
+package mainpack;
+
+public class Main {
+   public static void main(String args[]) {
+   System.out.println("Hello world");
+   }
+}
\ No newline at end of file
diff -r  -r 73c08b4cf501 module3/module-info.java
--- /dev/null
+++ b/module3/module-info.java
@@ -0,0 +1,5 @@
+module module3{
+requires module1;
+requires module2;
+   exports mainpack;
+}
\ No newline at end of file
diff -r  -r 73c08b4cf501 test.bat
--- /dev/null
+++ b/test.bat
@@ -0,0 +1,21 @@
+@echo off
+set JDK_HOME=
+set JDK_BIN=%JDK_HOME%\bin
+set JAVAC=%JDK_BIN%\javac
+set JAVA=%JDK_BIN%\java
+set CUR_DIR=%~dp0
+set OUT_DIR=%CUR_DIR%out
+set 

Re: RFR: JDK-8156602 - javac crashes again on Windows 32-bit with ClosedChannelException

[Jim Laskey (Oracle)]

This does work for the test provided.  The interrupted thread fails on the 
closed channel, but other theads continue to run on reopened channel.

The problem with the non-interruptible I/O is the jdk8 backport issue.  There 
is no way to use the non-interruptible read without loading new classes at 
start up (reflection or method handles.)  I could check version and use 
different paths on JDK-9 and JDK-8.

Other suggestions?

— Jim















> On May 19, 2016, at 10:46 AM, Alan Bateman  wrote:
> 
> On 19/05/2016 14:03, Jim Laskey (Oracle) wrote:
>> On 32 bit, a shared jimage channel closed by an interrupted thread 
>> (ClosedChannelException) disrupts other threads sharing jimage.  Fix is to 
>> reopen channel on not interrupted thread.
>> 
>> http://cr.openjdk.java.net/~jlaskey/8156602/webrev/index.html
>> https://bugs.openjdk.java.net/browse/JDK-8156602
> Does this work? The interrupt status isn't cleared so I would expect the 
> second and subsequent reads to fail and so hit the retry limit.
> 
> In generally them I'm uneasy about this approach and would prefer if we used 
> non-interruptible I/O. I don't mind working on it if you'd like to get rid of 
> it.
> 
> -Alan

Re: RFR: JDK-8156602 - javac crashes again on Windows 32-bit with ClosedChannelException

[Alan Bateman]

On 19/05/2016 14:03, Jim Laskey (Oracle) wrote:

On 32 bit, a shared jimage channel closed by an interrupted thread 
(ClosedChannelException) disrupts other threads sharing jimage.  Fix is to 
reopen channel on not interrupted thread.

http://cr.openjdk.java.net/~jlaskey/8156602/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8156602
Does this work? The interrupt status isn't cleared so I would expect the 
second and subsequent reads to fail and so hit the retry limit.


In generally them I'm uneasy about this approach and would prefer if we 
used non-interruptible I/O. I don't mind working on it if you'd like to 
get rid of it.


-Alan

Re: Review request: 8157068 ExceptionInInitializerError if images build patched to use exploded version of java.lang.module.SystemModules

[Mandy Chung]

> On May 18, 2016, at 11:27 PM, Alan Bateman  wrote:
> 
> On 19/05/2016 02:41, Mandy Chung wrote:
>> Webrev at:
>>   
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.00/index.html
>> 
>> This is to allow to patch java.base with an exploded image for JDK 
>> development purpose like this:
>> $ images/jdk/bin/java -Xpatch:java.base=jdk/modules/java.base -version
>> 
>> jdk.internal.module.SystemModules class is generated at link time to allow 
>> fast reconstitution of ModuleDescriptor.  If an image is patched with 
>> java.base of an exploded image, it will fall back to read and parse 
>> module-info.class from the jimage.  Hashes of tied modules are recorded in 
>> jdk.internal.module.SystemModules class in the fast path.  If patched, this 
>> fix will use the hashes recorded in the Hashes attribute for integrity check 
>> (that already validated at link time).
>> 
> A complicated scenario but the approach looks okay. No need to use 
> JavaLangModuleAccess to get at the hashes, just use descriptor.hashes().
> 

Ah, of course, SystemModuleFinder is in java.lang.module (I got mixed up with 
jdk.internal.module.SystemModules)

> The patch test directory already has a basic test for -Xpatch and might be 
> confusing to have the modules for both tests in the same tree. I wonder if we 
> should move each both tests in their own sub-directory to keep it easier to 
> understand.

That’s good.  I was looking for your opinion on this.  I considered putting 
them in a separate sub-directory and think it makes it clearer.  

Will move them before I push.

Mandy

Re: Fwd: Re: Modules with packages duplication

[Georgiy Rakov]

I've attached zip file with test.sh renamed to test_sh, hope this will help.

On 18.05.2016 18:16, Jonathan Gibbons wrote:
Without yet looking at your zip file, it is possible to compile 
classes that will not load in the application class loader, because of 
the restrictions defined for the boot layer. That does not imply the 
classes themselves are invalid, since they can be loaded and run in 
suitable configured layers/classloaders.


-- Jon


On 05/18/2016 05:53 AM, Georgiy Rakov wrote:


Hello Jon,

we've encountered situation when class files resulted from successful 
compilation cause runtime error; the sources are compiled by single 
javac invocation. This looks like incorrect javac behavior, namely it 
seems that javac should produce compile-time error if one tries to 
compile sources which will cause error at runtime. Could you please 
confirm if it's really is.


More details are provided in the forwarded message below. I have also 
attached an archive with minimized testcase and scripts to run it. In 
order to run it please:


1. Unzip attached archive to some machine (Windows or Unix);

2. If it's Windows rename test18/test_bat to test18/test.bat.

3. Modify JDK_HOME variable inside test18/test.bat (or 
test18/test.sh) to point to your JDK installation.


4. Run test18/test.bat (or test18/test.sh).

Thank you,

Georgiy.



 Forwarded Message 
Subject:Re: Modules with packages duplication
Date:   Thu, 05 May 2016 18:21:20 +0300
From:   Konstantin Barzilovich 
Organization:   Oracle Corporation
To: 	ML OpenJDK Jigsaw Developers , Alan 
Bateman 




Hello Alan,

Thank you for the answer.

I have one more question connected with duplication of packages.
Now we can compile two modules with the duplicated package without compile-time 
error if there is no module which can access both of them.
But in case of these two modules are readable by third module, in runtime it 
will result in error of boot Layer, as you said.
Is it okey, that compiler allow us to compile code, that will cause runtime 
failure?

Here is minimal test case:
--
module1/module-info.java
module module1 {
  exports pack;
}

module1/pack/A.java:
package pack;
public class A{}

module2/module-info.java
module module2 {
}

module2/pack/A.java:
package pack;
public class A{}

module3/module-info.java:
module module3{
  requires module1;
  requires module2;
}

Thanks,
Konstantin.

>
> On 04/05/2016 14:18, Konstantin Barzilovich wrote:
>> Hello,
>>
>> I can see that RI checks if there are packages with the same names in >> 
different modules (named or unnamed).
>> This check fails even if there is no clash (no module can read both >> 
packages).
>> Will it be the same in final version of JDK9 or it can be changed soon?
>>
> I think you are asking about modules on the application module path > (`java -modulepath ...`) 
that are resolved at startup. These are defined > to the application class loader so they cannot have 
overlapping > packages. It's trivial to do things like map each module in its own > class loader but 
that messes with visibility with lots of implications > (particularly when running with both a class 
path and module path or > where you bringing automatic modules into the picture). So what you are > 
seeing is specific to the boot Layer and no specific short term plans to > change this.
>
> -Alan

RFR: JDK-8156602 - javac crashes again on Windows 32-bit with ClosedChannelException

[Jim Laskey (Oracle)]

On 32 bit, a shared jimage channel closed by an interrupted thread 
(ClosedChannelException) disrupts other threads sharing jimage.  Fix is to 
reopen channel on not interrupted thread.

http://cr.openjdk.java.net/~jlaskey/8156602/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8156602

RE: Compact profiles broken?

[Uwe Schindler]

Hi,

that clearly explains what we are seeing. Elasticsearch and Apache Lucene/Solr 
are compiled with "-source 1.8 -target 1.8" and use the compact profile 
settings (Lucene Core with compact1, the rest with compact3, same for 
Elasticsearch).

This works everywhere, except for the javax crypto packages, because those are 
missing in the ct.properties file, that is used for source/target 1.8. Your 
explanation is very good, now I understand the problem! Thanks!

FYI, this also explains why we did not see a compile failure about the 
java.xml.bind issue (see previous mails)! This only failed at runtime, because 
with Jigsaw, the java.xml.bind is not exposed by the root modules. But while 
compiling it seems to see all those classes, as its compiled against 
source/target 8 where the module system is ignored. So there is also room for 
improvement! Alan?

So many thanks for this explanation!

Uwe

> -Original Message-
> From: Jan Lahoda [mailto:jan.lah...@oracle.com]
> Sent: Thursday, May 19, 2016 12:34 PM
> To: Uwe Schindler ; 'Alan Bateman'
> ; jigsaw-dev@openjdk.java.net
> Subject: Re: Compact profiles broken?
> 
> This appears to be a bug in the current profiles handling in javac -
> currently (without "-release X"), javac uses "ct.properties" to
> determine the profile of a class. This file contains mapping from
> package to extra metadata, esp. profile. And this file does not contain
> mapping for javax.crypto, so javac thinks it belongs to the default profile.
> 
> I guess this is because ct.properties only contains mapping for packages
> from rt.jar, and javax.crypto was not part of rt.jar (was in jce.jar).
> 
> It would be relatively easy to use modules to detect profiles, but there
> is a problem with "-source 8 -profile compactX", as with -source 8,
> javac does not keep information about modules, and so cannot do
> module-based checks. So I guess we may need to regenerate ct.properties.
> 
> Jan
> 
> On 19.5.2016 09:10, Uwe Schindler wrote:
> > Hi Alan,
> >
> > Interestingly, compiling large amounts of code with the Java SE8 option for
> "compact1" or "compact3" works successfully. It is just this class/package
> failing. How can that be? The issue is not visible to the outside (requires
> login).
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > uschind...@apache.org
> > ASF Member, Apache Lucene PMC / Committer
> > Bremen, Germany
> > http://lucene.apache.org/
> >
> >> -Original Message-
> >> From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On
> Behalf
> >> Of Alan Bateman
> >> Sent: Thursday, May 19, 2016 8:55 AM
> >> To: Ryan Ernst ; jigsaw-dev@openjdk.java.net
> >> Subject: Re: Compact profiles broken?
> >>
> >> On 19/05/2016 06:49, Alan Bateman wrote:
> >>> :
> >>>
> >>> In the mean-time then this should work:
> >>>
> >>>java -release 8 -profile compact3 ...
> >>>
> >>> or specify -limitmods, as in:
> >>>
> >>>java -limitmods java.compact3 ...
> >>>
> >> Oops, I meant `javac` here of course (not `java`).
> >>
> >> -Alan
> >

Re: 8148834: Update module-info reader/writer to 53.0

[Chris Hegarty]

On 19 May 2016, at 12:49, Alan Bateman  wrote:

> javac has been switched to generate v53.0 class files. ASM, pack200 and 
> several other areas have been updated too. We have two places in the 
> module-info reader/writing that needs to be updated so I need a Reviewer to 
> get this into jdk9/dev.
> 
> -Alan
> 
> diff --git a/src/java.base/share/classes/java/lang/module/ModuleInfo.java 
> b/src/java.base/share/classes/java/lang/module/ModuleInfo.java
> --- a/src/java.base/share/classes/java/lang/module/ModuleInfo.java
> +++ b/src/java.base/share/classes/java/lang/module/ModuleInfo.java
> @@ -154,7 +154,7 @@
> int minor_version = in.readUnsignedShort();
> int major_version = in.readUnsignedShort();
> if (major_version < 53) {
> -// throw invalidModuleDescriptor"Must be >= 53.0");
> +throw invalidModuleDescriptor("Must be >= 53.0");
> }
> 
> ConstantPool cpool = new ConstantPool(in);
> diff --git 
> a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java 
> b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
> --- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
> +++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
> @@ -54,7 +54,7 @@
> ClassWriter cw = new ClassWriter(0);
> 
> String name = md.name().replace('.', '/') + "/module-info";
> -cw.visit(Opcodes.V1_8, ACC_MODULE, name, null, null, null);
> +cw.visit(Opcodes.V1_9, ACC_MODULE, name, null, null, null);
> 
> cw.visitAttribute(new ModuleAttribute(md));
> cw.visitAttribute(new ConcealedPackagesAttribute(md.conceals()));

This looks good to me Alan.

-Chris.

Re: 8157290: jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java failing

[Chris Hegarty]

On 19 May 2016, at 11:26, Alan Bateman  wrote:

> 
> The jdk9/client -> jdk9/dev integration yesterday included the fix for 
> JDK-8154539 which breaks a test that has been assuming sun.misc is in 
> java.base. I suspect this test was missed in previous rounds that laid the 
> ground for jdk.unsupported. Trivial change to get the test back to use a 
> package that overlaps with a package in java.base.
> 
> http://cr.openjdk.java.net/~alanb/8157290/webrev/

This looks fine. Yes, it was missed in previous jdk.unsupported changes.

-Chris.

Re: 8148834: Update module-info reader/writer to 53.0

[Sundararajan Athijegannathan]

+1


On 5/19/2016 5:19 PM, Alan Bateman wrote:
> javac has been switched to generate v53.0 class files. ASM, pack200
> and several other areas have been updated too. We have two places in
> the module-info reader/writing that needs to be updated so I need a
> Reviewer to get this into jdk9/dev.
>
> -Alan
>
> diff --git
> a/src/java.base/share/classes/java/lang/module/ModuleInfo.java
> b/src/java.base/share/classes/java/lang/module/ModuleInfo.java
> --- a/src/java.base/share/classes/java/lang/module/ModuleInfo.java
> +++ b/src/java.base/share/classes/java/lang/module/ModuleInfo.java
> @@ -154,7 +154,7 @@
>  int minor_version = in.readUnsignedShort();
>  int major_version = in.readUnsignedShort();
>  if (major_version < 53) {
> -// throw invalidModuleDescriptor"Must be >= 53.0");
> +throw invalidModuleDescriptor("Must be >= 53.0");
>  }
>
>  ConstantPool cpool = new ConstantPool(in);
> diff --git
> a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
> b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
> ---
> a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
> +++
> b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
> @@ -54,7 +54,7 @@
>  ClassWriter cw = new ClassWriter(0);
>
>  String name = md.name().replace('.', '/') + "/module-info";
> -cw.visit(Opcodes.V1_8, ACC_MODULE, name, null, null, null);
> +cw.visit(Opcodes.V1_9, ACC_MODULE, name, null, null, null);
>
>  cw.visitAttribute(new ModuleAttribute(md));
>  cw.visitAttribute(new
> ConcealedPackagesAttribute(md.conceals()));

8148834: Update module-info reader/writer to 53.0

[Alan Bateman]

javac has been switched to generate v53.0 class files. ASM, pack200 and 
several other areas have been updated too. We have two places in the 
module-info reader/writing that needs to be updated so I need a Reviewer 
to get this into jdk9/dev.


-Alan

diff --git 
a/src/java.base/share/classes/java/lang/module/ModuleInfo.java 
b/src/java.base/share/classes/java/lang/module/ModuleInfo.java

--- a/src/java.base/share/classes/java/lang/module/ModuleInfo.java
+++ b/src/java.base/share/classes/java/lang/module/ModuleInfo.java
@@ -154,7 +154,7 @@
 int minor_version = in.readUnsignedShort();
 int major_version = in.readUnsignedShort();
 if (major_version < 53) {
-// throw invalidModuleDescriptor"Must be >= 53.0");
+throw invalidModuleDescriptor("Must be >= 53.0");
 }

 ConstantPool cpool = new ConstantPool(in);
diff --git 
a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java 
b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java

--- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
+++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
@@ -54,7 +54,7 @@
 ClassWriter cw = new ClassWriter(0);

 String name = md.name().replace('.', '/') + "/module-info";
-cw.visit(Opcodes.V1_8, ACC_MODULE, name, null, null, null);
+cw.visit(Opcodes.V1_9, ACC_MODULE, name, null, null, null);

 cw.visitAttribute(new ModuleAttribute(md));
 cw.visitAttribute(new ConcealedPackagesAttribute(md.conceals()));

RE: Compact profiles broken?

[Uwe Schindler]

Hi Alan,

Interestingly, compiling large amounts of code with the Java SE8 option for 
"compact1" or "compact3" works successfully. It is just this class/package 
failing. How can that be? The issue is not visible to the outside (requires 
login).

Uwe

-
Uwe Schindler
uschind...@apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -Original Message-
> From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf
> Of Alan Bateman
> Sent: Thursday, May 19, 2016 8:55 AM
> To: Ryan Ernst ; jigsaw-dev@openjdk.java.net
> Subject: Re: Compact profiles broken?
> 
> On 19/05/2016 06:49, Alan Bateman wrote:
> > :
> >
> > In the mean-time then this should work:
> >
> >   java -release 8 -profile compact3 ...
> >
> > or specify -limitmods, as in:
> >
> >   java -limitmods java.compact3 ...
> >
> Oops, I meant `javac` here of course (not `java`).
> 
> -Alan

Re: Compact profiles broken?

[Alan Bateman]

On 19/05/2016 06:49, Alan Bateman wrote:

:

In the mean-time then this should work:

  java -release 8 -profile compact3 ...

or specify -limitmods, as in:

  java -limitmods java.compact3 ...


Oops, I meant `javac` here of course (not `java`).

-Alan

Re: Review request: 8157068 ExceptionInInitializerError if images build patched to use exploded version of java.lang.module.SystemModules

[Alan Bateman]

On 19/05/2016 02:41, Mandy Chung wrote:

Webrev at:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.00/index.html

This is to allow to patch java.base with an exploded image for JDK development 
purpose like this:
$ images/jdk/bin/java -Xpatch:java.base=jdk/modules/java.base -version

jdk.internal.module.SystemModules class is generated at link time to allow fast 
reconstitution of ModuleDescriptor.  If an image is patched with java.base of 
an exploded image, it will fall back to read and parse module-info.class from 
the jimage.  Hashes of tied modules are recorded in 
jdk.internal.module.SystemModules class in the fast path.  If patched, this fix 
will use the hashes recorded in the Hashes attribute for integrity check (that 
already validated at link time).

A complicated scenario but the approach looks okay. No need to use 
JavaLangModuleAccess to get at the hashes, just use descriptor.hashes().


The patch test directory already has a basic test for -Xpatch and might 
be confusing to have the modules for both tests in the same tree. I 
wonder if we should move each both tests in their own sub-directory to 
keep it easier to understand.


-Alan.