JDK support for VM to read classes from modules in a module library

[Mandy Chung]

On 5/16/2012 10:42 AM, Alan Bateman wrote:
> On 05/05/2012 07:38, Mandy Chung wrote:
>> :
>> You can also look at all changes together in this webrev:
>>    
>> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/
>>
> I've gone through the changes in the combined webrev, except for 
> jigsaw.c where I only skimmed it because it's tied to the current 
> configuration and so will change.
>
> I think the native interface looks fine, the only minor comment is 
> that I'd probably use typedef struct module.

Yes, I should use typedef.

>
> Of the Class.forName usages that have changed then one that didn't 
> look right is Properties where the workaround is to use the loader for 
> the base module to load XMLUtils. Given that XMLUtil is currently in 
> the jaxp module (and I know this isn't quite right either as JAXP is a 
> standalone technology etc.) then I would think that the Properties 
> code will need to do a Class.forName on an exported javax.xml type and 
> use that loader (or alternative use jdk.jaxp).
>

We should change Class.forName to look for "javax.xml" type instead of 
"sun.util.xml.XMLUtils" since XMLUtils will be moved out from jaxp 
module as JAXP is a standalone technology.

The workaround is also related to that Class.forName fails to find a 
class with a null loader (jdk.base requires jdk.jaxp.internal that 
exports sun.util.xml) that I leave it as an open issue to be 
investigated. Are you ok if I push this patch as it is and follow this 
as a separate patch (probably together with moving out XMLUtils from 
jdk.jaxp)?

> In ServiceLoader you've changed the comment at L515 to "caller's class 
> loader" but it should be  "the caller's caller's class loader".
>

Would it be better to say "class loader of the caller of 
ServiceLoader.load* method"?

> I didn't quite get why src/share/native/java/lang/System.c was 
> changed, was this for debugging?
>

Improve the diagnosibilty.  Change to the VM initialization sequence is 
hard to diagnose.  I ran into a bug of mine that causes reading of 
system  properties while it's being initialized.  The change was to 
improve the diagnostic message and the system initialization is evolving 
during jigsaw development and this might be useful.  BTW, the 
InternalError is only thrown in jigsaw/jigsaw.   At some point, we will 
port this to jdk8 if it's helpful.

> Otherwise I look forward to see this in, along with Karen's patch.
>

Thank you.
Mandy