Mutable modules

[Alan Bateman]

On 18/05/2016 17:13, David M. Lloyd wrote:
>
> At present, you can remove a module or a bundle even if existing 
> dependent module classes are statically referring to their contents. 
> It'll work fine as long as those classes haven't been loaded yet.  So 
> we'd basically be taking away this capability with the code as it is, 
> if we try to put existing deployments or bundles into named Modules.
When you say "remove a module" then do you mean the module artifact, as 
in the JAR file?

At least for built-in class loaders then a module artifactsis opened 
lazily when the first class in the module is loaded. It's possible of 
course for someone to be loading from modules with their own class 
loaders where module artifacts are opened eagerly (not something the JDK 
can control).

That said, if you really do mean removing or replacing module artifacts 
that are potentially in use then you are skating on thin ice. The system 
could blow up at any time.

>
> Another thing presently possible is expanding the existing class path 
> of a deployment module, and replacing class contents (again this may 
> fail if any of the replaced classes were already loaded).
When you say "class path of a deployment module" then do you mean a side 
class path, meaning loading code that is not in a named module? There 
aren't any changes there.

I might not understand what you mean here but just to say that you can 
create a layer of modules where the class loaders for the modules in 
that layer delegate to a parent class loader for types that are not in 
named modules. If that class loader can dynamically expand then it 
should just work as before.

>
> To expand it more to a logical statement, the set of capabilities 
> allowed to a class loader is greater than the set allowed to a named 
> module, so as long as this is true, moving to named modules will 
> necessarily cost functionality.
There are different concepts so I'm not sure how to answer this.

>
> Would it be possible to somehow allow the unnamed module to, well, 
> have a name (and a version string), so that it appears in stack traces?
>
It would be an oxymoron for unnamed modules to have names and would lead 
to some inconsistencies (Module::isNamed would return false but 
Module::getName would return a name???). However, technically then if 
you could name a ClassLoader then its unnamed Module could have a name. 
I'm not sure that we want to go there.

-Alan.