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.
