Mutable modules

[Alan Bateman]

On 18/05/2016 22:47, David M. Lloyd wrote:
>
> 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 don't think I can relate to the use case. As you probably know then 
ZIP files have historically had their central directory mapped into 
memory. Removing or replacing a file that is memory mapped will likely 
lead to processes accessing the mapped file to crash (SIGBUS usually). 
So if users are really doing such hairy things they would need a lot of 
insight into what is running and whether the file is opened before 
taking this risk.


>  :
>
> 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).
If there are cyclic relationships between your modules then it will be 
problematic. Do you see much of this? If you've read Alex's JavaOne 
slides then you'll know that some of us like Kirk Knoernschild's book on 
Java Application Architecture and section "4.4 Cyclic Dependencies - the 
Death Knell" where he poses the question "Are Cycles Always Bad?". I 
don't want to say too much on this topic here as it is listed as an open 
issue on the JSR issues list.

>
> 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. 
Aside from cycles then what other use-cases do you have here? I read 
"change the resource loader list" to mean that the set of resources in 
the module changes, which is a bit weird if those resources are class 
files that have already been loaded. Maybe there is dynamic code 
generation with class bytes generated to the file system or into 
somewhere virtual? Or maybe these resources are something else, data 
files? I'm just trying to understand what you mean as we are using 
differently terminology.

> 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.
This sounds like class loader delegation to resolve types that are not 
in the module.

>
> 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.
Suppose that module m has package p and p.C has been loaded. Are you 
saying that you can drop package p from the module?

As things currently stand in JDK 9 then packages may be added to modules 
at runtime, the main use case is the dynamic proxy to a public interface 
in a non-exported packages. So I can relate to adding packages for code 
gen cases, I'm less sure about a module starting out as an XML API and 
suddenly changing into a JDBC driver. Do you really mean the same module 
instance?

>
> 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?
Using module names as an example, then it should be possible to develop 
a module that is deployed on the application module path or instantiated 
in a layer of modules that a container creates. The author of the module 
(that chooses the name) isn't going to know in advance how the module is 
deployed. I'm not even sure how such a module could be compiled or how 
anyone could depend on it when the characters or format can vary like 
this. I see there is an issue on the JSR issues list so I don't want to 
say any more on this topic.


> 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.
The module system imposes surprising few constraints.  If you are using 
your own class loaders then the delegation needs to respect module 
readability, something that should not be controversial.

However it is possible that you are still at the starting line because 
your have a dependency graph with cycles and/or modules that don't have 
names that can be expressed as a Java identifier, is that right?


>
> 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.
I'm surprised that this is an issue as module membership is critical to 
access control.

-Alan.