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

[David M. Lloyd]

Thanks for replying, responses inline.

On 07/20/2012 09:29 AM, Paul Sandoz wrote:
> 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.

Thanks, it's helpful to see where you see these equivalencies.

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

I do disagree with the way the abstractions are structured and 
expressed.  Many (most?) of these abstractions belong in the module API, 
not in the Jigsaw implementation classes.  The module API has to be 
constrained enough to define a specific behavior; as it stands it is 
very general.  But I don't want to tangent off into specific 
implementation details: I have many ideas and opinions about how things 
*should* be structured but that's a different discussion.

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

This matches my understanding, though it's not just a path when it comes 
to compilation: allowing a pluggable loader repository even in this case 
is important to (for example) OS distributions who don't necessarily 
*want* to coordinate a binary database of installed Java modules with 
their installation tools, or special build or CI tools which want to set 
up mock environments for integration testing.

> 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!
> :-)

I am curious: how does this behave in terms of java.lang.reflect.Module? 
  Opting to make this a language construct means you need to "feed in" 
annotations among other things and I don't see where that could happen. 
  This is one place where the fit is wrong IMO: you don't gain anything 
by having a module be a new reflective construct that you don't already 
have by drawing a 1:1 correspondence between a Module and a ClassLoader, 
which you *would* be able to do if not for the erroneous requirement 
that the individual core JDK pieces be separate modules with the same 
class loader.  That requirement is better written something like: "The 
core JDK must be distributable in separate components that correspond to 
X, Y, Z (justification: distro size, ME growth, etc.).  The core JDK 
classes must all present the same class loader (or, a null class loader 
depending on how that analysis pans out) (justification: compatibility 
with system class loader based schemes, etc.)".

-- 
- DML