jigsaw now sync'ed with jdk8-b23

[Mandy Chung]

On 2/1/2012 10:41 AM, Alan Bateman wrote:
> Actually I think you're right, we can take some of the SL changes to 
> get a bit further but we run into another issue with a Class.forName 
> usage in sun.font.FontManagerFactory. 

Thanks for getting the fix for it.   I missed this issue when testing 
the module views work.

Oh yeah, this is one of those in the jdk implementation that depends on 
the tradition class loading delegation model.  At some point, we'll look 
at all class-loader related usage.

> Here's the webrev the patch to get it going:
>
> http://cr.openjdk.java.net/~alanb/fmf-patch/webrev/

FontManagerFactory.java
    L78:  It's fine to call BootLoader.getSystemLoader() as a workaround 
for now.
    This assumes that the class is visible to the BootLoader and it works in
    the current prototype since jdk.desktop requires local 
jdk.base.internal.
    It'll fail if an alternate class specified through the property is in
    another module.  I think it would use the module loader loading this
    FontManagerFactory class.  I have a patch that adds the
    Class.getModuleClassLoader method but it's coupled with the legacy
    mode support.  I can modify this FontManagerFactory class in the legacy
    mode support work.

ServiceLoader.java
    L482, 515, 548: seems like it's time to add a convenient method to 
determine
    if it's in module mode or legacy mode. In the current prototype, 
BootLoader
    only gets created in module mode but it may also be created with the
    legacy mode support.   If it gets changed, this would be isolated in 
this
    single method. (sorry I should have added that convenient method in my
    last changeset).

    L483: if loader == null, should it use BootLoader.getSystemLoader() 
instead?

Mandy