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

Mandy Chung mandy.chung at oracle.com
Thu May 19 13:33:24 UTC 2016


> On May 18, 2016, at 11:27 PM, Alan Bateman <alan.bateman at oracle.com> 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


More information about the jigsaw-dev mailing list