Patch-module with dynamic layer creating.

[Alan Bateman]

On 13/10/2018 08:54, Alex Sviridov wrote:
> :
> I am sorry, maybe I didn't express this very clear: I mean something like this:
>   ModuleLayer layer = parent.defineModulesWithOneLoader(cf, scl, args); Where args are for example String[] and we pass the same --add-exports, --add-opens, --patch-module,
> --add-modules, --add-reads etc that we pass to configure boot layer. The disadvantage of such way
> is using String. However, there are two main advantages: 1) no line of code 2) use the same parameters
> that we use to configure boot layer - one solution within one technology.
>
I don't think this is the right approach either. It would mean 
standardizing what is currently JDK specific command line options. In 
addition it impacts Configuration resolve and resolveAndBind because 
--add-modules adds to the set of root modules to resolve (also you need 
the patched modules to be observable at this time too).

If it helps, I think this is what you need to do:

--add-modules
Add the names of the modules to the root set that you specify to 
Configuration resolve and resolveAndBind.

--patch-module
Provide a ModuleFinder that interposes on the unpatched module to 
override or augment its resources. This should be the only case where 
you need to write a lot of code (mundane rather than hard). There may be 
an opportunity to develop this as its own project in the event that 
there is wider interest in patching modules.

--add-reads, --add-exports, --add-opens
Are you sure you need these? If you then use the static 
ModuleLayer.defineModulesWithOneLoader method to specify the parent 
layer as a parameter rather than the receiver. This will return you a 
ModuleLayer.Controller object that you can use to do the equivalent of 
these CLI options, at least for the cases where the target is a specific 
module.

-Alan.