jigsaw now sync'ed with jdk8-b23
mandy.chung at oracle.com
Wed Feb 1 11:47:37 PST 2012
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:
L78: It's fine to call BootLoader.getSystemLoader() as a workaround
This assumes that the class is visible to the BootLoader and it works in
the current prototype since jdk.desktop requires local
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.
L482, 515, 548: seems like it's time to add a convenient method to
if it's in module mode or legacy mode. In the current prototype,
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
single method. (sorry I should have added that convenient method in my
L483: if loader == null, should it use BootLoader.getSystemLoader()
More information about the jigsaw-dev