jigsaw now sync'ed with jdk8-b23
Alan.Bateman at oracle.com
Wed Feb 1 12:01:02 PST 2012
On 01/02/2012 19:47, Mandy Chung wrote:
> 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.
Right, and I'll sure we will have many of these.
> 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
> 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
> mode support work.
In legacy mode it should work the way it has always worked and find the
font manager on the system class path. Not clear how it should work in
module mode so I decided that BootLoader would be the most sensible for
now. I think this will need to be changed (several other places too)
once we are further along.
> 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 this
> single method. (sorry I should have added that convenient method in my
> last changeset).
> L483: if loader == null, should it use BootLoader.getSystemLoader()
I don't think so because in module mode we want existing code that calls
it with null to use the caller's class loader. I agree we need to add a
method to indicate if are in module mode.
More information about the jigsaw-dev