Extents of extensibility ("is this thing on?")

[Paul Sandoz]

Hi David,

Thanks for sending a link to the JavaDoc.

If i could make some loose analogies:

- org.jboss.modules.ModuleLoader is similar to org.openjdk.jigsaw.Configuration<T extends BaseContext> + Catalog

- Module is similar to T extends BaseContext; and

- ModuleClassLoader is similar to Loader.

There are two instantiations of Configuration, Configuration<Context> and Configuration<PathContext>. The former is an install-time configuration (and serialized in a library and used for execution of a main class) and the latter is a compile-time configuration. A configuration is the result of resolving and linking, and linking differs depending on whether one is installing or compiling.

Catalog abstracts the layout of modules.

Can these Jigsaw abstractions be improved? almost certainly since this is currently prototype code.

There are at least two areas that may impact the implementations/abstractions:

- compiling and running with a path of jmod, modular jars, and/or exploded compiled modules in addition to modules installed into libraries; and

- container support, which would enable that one-way delegation you refer to.

FWIW the tests for the resolver create a mock Library (an implementation of Catalog) and build ModuleInfo instances using a ModuleInfoBuilder i.e. not from a module-info.java/class, shocking! :-)

Paul.

On Jul 17, 2012, at 6:04 PM, David M. Lloyd wrote:
> Jigsaw still has one glaring hole in it which is a critical flaw: lack of extensibility.
> 
> There is no abstraction layer which would allow users to define their own module loading and definition scheme.  This is directly related to the way the module class loader, module, and module system APIs fit together.
> 
> Note that this is tied directly to the flawed notion of having a language-level construct for modules, which is ONLY done this way because of the murky "requirement" that modules be "part of the language".  As is often the case, this "feature" translates directly into a major constraint: it is impossible to achieve the above.
> 
> This requirement is senseless; I don't think more needs to be said, as the burden of justification lies with the requirement author.  By opening up module loading schemes to the user, the user can leverage the module system's (presumably) fast and powerful linking layer for their own plugin systems and containers - and this also "holds the door" open for a modular progression for Java EE, which is something, I might add, that we have already executed on with great success.
> 
> We have a ModuleLoader API [1] which provides for one-way delegation (think EE deployments delegating to the static boot module system), module unloading (but only for *your* module loader), and run-time module relinking, as well as being a touchstone for statistics and other run-time class loading management information.  We provide a default "boot" implementation which loads static module definitions off of the file system.
> 
> This API works *really well* for our uses and also allows users to create their own plugin schemes while still defining dependencies and filters in all the same ways that they would for static modules - which really stands to revolutionize how people write plugins.
> 
> Please consider abstracting module loading out into a separate API concept.  It is a good, solid approach.
> 
> [1] http://docs.jboss.org/jbossmodules/1.1.2.GA/api/index.html?org/jboss/modules/ModuleLoader.html
> -- 
> - DML