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

[Paul Sandoz]

Hi,

Sorry for the late reply.

On Jul 20, 2012, at 9:39 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:

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

I would not read too much into what classes are in what packages at the moment, it is highly likely this will all change.


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

Annotations are not currently supported in module-info.java and the corresponding ModuleInfo. It's still an open question if that should be the case or not. 

For those tests i referred to the runtime does not kick in, thus a Module is not instantiated (which is when a module is defined by the ModuleClassLoader). 

The module CL, Loader, has a Context. It's not the other way around since that association is only relevant at runtime, not at install time or compile time.


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

I would not go so far as to say erroneous, there are pros/cons. However, i think the cons outweigh the pros, it would simplify the Module system and it's usage if "requires local" did not exist, and IIRC it is likely that the JDK modules will not require it with a careful sprinkling of optional dependencies, services and some VM tweaks.

Note that not all modules in the JDK are in the same context and therefore have the same CL, only those for which there remains the issue that they cannot currently be separated. You can see the association between a module and a context by dumping a configuration, for example:

$ ./build/macosx-x86_64/bin/jmod dump-config jdk.tools | grep context
  context +jdk.tools.jaxws
  context +jdk.management+jdk.management.iiop
  context +jdk.corba
  context +jdk.jaxws
  context +jdk.rmi
  context +jdk.scripting
  context +jdk.jta
  context +jdk.compiler
  context +jdk.jx.annotations
  context +jdk.zipfs
  context +jdk.httpserver
  context +jdk.tools.jre
  context +jdk.logging
  context +jdk.tools.base
  context +jdk.auth+jdk.base+jdk.desktop+jdk.jndi+jdk.prefs+jdk.tls+sun.charsets+sun.localedata+sun.resources
  context +jdk.devtools
  context +jdk.tools
  context +jdk.jaxp

The code which groups modules to a context is in ContextBuilder. It's an easy feature to remove from the resolving and linking process.

Paul.

>  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