ModuleLayer.defineModules function clf must be stateful?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ModuleLayer.defineModules function clf must be stateful?

Thomas Watson-2
I noticed that the clf function passed to
ModuleLayer.defineModules(Configuration, List<ModuleLayer>,
Function<String, ClassLoader>) is called at least twice for every module
name contained in the new ModuleLayer.  Once for the call
to java.lang.ModuleLayer.checkForDuplicatePkgs(Configuration,
Function<String, ClassLoader>) and once for the call
to java.lang.Module.defineModules(Configuration, Function<String,
ClassLoader>, ModuleLayer)

In my case I was returning a new ClassLoader object each call to my clf
function.  But I noticed that I was creating twice as many class loaders
than needed for the ModuleLayer.  Ultimately it looks like the
checkForDuplciatePkgs method throws away the created ClassLoader and then
the second call to my clf in defineModules gets the actual class loader
that will be used by the module.  My question: is this expected?  Is my
function expected to hold state and return the same class loader object
each time it is called for a specific module name?

Tom
Reply | Threaded
Open this post in threaded view
|

Re: ModuleLayer.defineModules function clf must be stateful?

Alan Bateman
On 26/02/2019 19:38, Thomas Watson wrote:

> I noticed that the clf function passed to
> ModuleLayer.defineModules(Configuration, List<ModuleLayer>,
> Function<String, ClassLoader>) is called at least twice for every module
> name contained in the new ModuleLayer.  Once for the call
> to java.lang.ModuleLayer.checkForDuplicatePkgs(Configuration,
> Function<String, ClassLoader>) and once for the call
> to java.lang.Module.defineModules(Configuration, Function<String,
> ClassLoader>, ModuleLayer)
>
> In my case I was returning a new ClassLoader object each call to my clf
> function.  But I noticed that I was creating twice as many class loaders
> than needed for the ModuleLayer.  Ultimately it looks like the
> checkForDuplciatePkgs method throws away the created ClassLoader and then
> the second call to my clf in defineModules gets the actual class loader
> that will be used by the module.  My question: is this expected?  Is my
> function expected to hold state and return the same class loader object
> each time it is called for a specific module name?
The original intention is that it be a pure function but the spec isn't
clear on that. In addition, the implementation can't trust any of the
parameters so it will have to memorize the class loader which amounts to
calling the mapping function once per module. Can you submit a bug for this?

-Alan