Whitelisting modules in layers

[Alan Bateman]

On 01/12/2017 18:47, Mark Raynsford wrote:
> :
>
> I've played around with the ModuleFinder API a little, and came up
> with the following:
>
>    https://github.com/io7m/moduledemo-20171201/blob/master/src/main/java/com/io7m/moduledemo/WhitelistModuleDemo.java
>
> However, the boot_layer.defineModulesWithOneLoader() call raises an
> exception: "Class loader must be the boot class loader". Clearly I'm
> not meant to use the API in this way!
It looks like this demo is attempting to create a module layer from a 
configuration that contains java.base. The java.base module is in the 
boot layer, alternative implementations of java.base are not allowed in 
other layers (java.base is special in this regard and the 
defineModulesXXX methods are all specified to throw 
LayerInstaniationException if the configuration contains java.base).

If I understand your mail correctly then your "white list" is like the 
`--limit-modules` CLI option in that it is trying to limit the 
observability of the modules. One initial comment on this is that you 
need to compute the transitive closure (or recursive enumeration in 
resolution speak) of the set of modules for this to work. This will 
become clear once you have a com.example.m* module that requires a 
module other than java.base.

On your question then the module layer API doesn't provide a way to 
"hide" modules in the parent layers. You can override any module (except 
java.base) with an alternative implementation in the child layer but it 
doesn't provide anyway to hide modules that you aren't overriding. This 
may not be an issue for what you are doing. If you need to, then compute 
the set of modules that you want to hide and make empty versions of each 
of these observable via the "before" ModuleFinder that you specify to 
resolve. You could use an intermediate module layer to do this if you want.

-Alan