Mutable modules

[David M. Lloyd]

On 05/18/2016 12:36 PM, Alan Bateman wrote:
> 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 mean in *our* current concept of a module, we can add/remove/modify 
the contents of a module (its "class path") at run time.  It is up to 
the user to ensure that doing so makes sense.

> 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.

What I'm really trying to do here is to shoehorn our current module 
concept into Jigsaw's so we can get the benefit of nice stack traces and 
maybe some measure of interoperability.  I could just *not* do that, and 
say, well, our deployments can never be Jigsaw modules, but if Java EE 9 
rolls around and makes everyone use named modules for applications, 
we're going to be severely broken.

Our modules each correspond to their own class loader: so far so good, 
we can just have one Module per class loader.  Problem is that we 
support circularity, and also we support dependencies that go across 
module systems with isolated namespaces (basically, our module loaders 
are a higher order of the exact same concept of class loaders).

Our modules support specifications including the content of the module 
("resource loaders") and the dependencies of the module.  At run time, 
custom ModuleLoader implementations can change the resource loader list 
and/or the dependency list at any time, causing the module to be 
relinked on the spot; the most useful aspect of this is the ability to 
incrementally deploy applications which may include circular 
dependencies.  We also support delegating "fallback" class loading 
decisions to outside suppliers for dynamic class loading behavior (this 
was done to support a dynamic OSGi environment).  The ongoing integrity 
of the system is up to the party doing the relinking (the EE deployer or 
the OSGi resolver); most of the time it can reason about what is "safe" 
and what might cause system breakage (but still might be useful to do 
anyway).  These are the features we can't seem to support under Jigsaw, 
architecturally speaking.

Specifically this includes (but is not limited to) changing the package 
set associated with a JDK module at run time, something that this native 
code block makes impossible.  Also the ability to dynamically change 
module dependencies is an essential ingredient to making this work.

In my view, architecturally speaking, most of the constraints imposed by 
the core module framework should be layer policy.  If the system's core 
module layer wants to maintain strict, static integrity, name 
constraints, version syntax and semantics, etc., that's fine, but why 
should all modules everywhere be forced to the same constraints?  There 
is no way that existing containers and class loading environments (other 
than, apparently, WebLogic) can conform to Jigsaw's constraints without 
losing functionality (and I'm trying hard to find ways to make it work). 
  This is where most of my raised issues are coming from.

All these problems seem surmountable to me, but it becomes substantially 
more difficult when it is necessary to report all of a module's packages 
to the module when it is created, since this information is now not 
easily changed.

>> 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.

In lieu of actually creating Modules via Configurations, I'd be 
satisfied with maintaining only the appearance of having created a 
Module (including parsing out the descriptors and translating them into 
JBoss-compatible deployment information) as long as we got the stack 
traces and any other useful module metadata such that a Jigsaw module 
application cannot tell the difference.  I can interoperate with real 
Jigsaw modules in the same way we interoperate with the JDK today - as a 
one-way relationship.

-- 
- DML