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
