Patch-module with dynamic layer creating.
Alan Bateman
Alan.Bateman at oracle.com
Sat Oct 13 08:25:34 UTC 2018
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.
More information about the jigsaw-dev
mailing list