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

[Alan Bateman]

On 16/05/2012 19:44, Mandy Chung wrote:
>
> 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)?
Yes, I'm okay with this as the we need to move this forward and get the 
native interface and VM changes in place. We can come to an agreement on 
what to do with JAXP in the continuation of the thread.

>
>> 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"?
That's fine.


>
>> 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.
My preference is that anything that isn't Jigsaw specific should be 
pushed upstream to jdk8 so that we aren't carrying too many changes.

-Alan.