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
