Adding boot and platform module flags to ResolvedModule

[Scott Stark]

In the prototype that allows the vm to boot with modules on the module path that have packages with the same name, I have modified the ModuleBootstrap to use an alternate Function<String, ClassLoader> mapping that creates a jdk.internal.loader.Loader for the modules that are not in the set of boot/platform modules so that duplicate packages in separate modules do not cause the vm to fail the boot phase. Attached is the very rough first version of the prototype. Most of the changes are just System.err.printf statements to debug what is happening during the bootstrap phase.

There are a couple of places that need to know whether a module is in the boot/platform set in order to assign the correct ClassLoader.

----- Original Message -----
From: "Alan Bateman" <Alan.Bateman at oracle.com>
To: "Scott Stark" <sstark at redhat.com>, jigsaw-dev at openjdk.java.net
Sent: Thursday, October 6, 2016 9:29:57 AM
Subject: Re: Adding boot and platform module flags to ResolvedModule

On 06/10/2016 17:15, Scott Stark wrote:

> Hello,
>
> I'm currently prototyping an alternate bootstrap implementation that will allow packages with the same name to exist across modules, and one thing I have run across is the need to know what the boot and platform modules are since there are restrictions on what type of ClassLoader can be used with them. Currently this information is located in the
> jdk.internal.module.ModuleLoaderMap class. In my prototype I just exposed that info via static public methods on ModuleLoaderMap, but it seems like the appropriate place for this is as read only attributes on the java.lang.module.ResolvedModule class.
>
> Does that make sense?
ModuleLoaderMap is generated at build time with the mapping of modules 
to loader. Once the VM initialized then there shouldn't be any further 
need for it and not clear that it would be worth exposing it in the API. 
Maybe you could expand a bit more on what you doing as it's hard to 
understand how you might use this.

-Alan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sms.diff
Type: text/x-patch
Size: 18337 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/jigsaw-dev/attachments/20161006/1ce71909/sms-0001.diff>