[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jigsaw-dev
Subject:    Extents of extensibility ("is this thing on?")
From:       paul.sandoz () oracle ! com (Paul Sandoz)
Date:       2012-07-31 4:14:30
Message-ID: 990BB533-9EBB-456F-A2AF-B5EFAEC04D44 () oracle ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]