[jsr294-modularity-eg] Simple Module System Proposal

[Stephen J. McConnell]

BJ, Richard, Peter:

Having read the proposal for a proposal a couple of times it seems to me
that some specifics need to teased out.

1. The proposal asserts the existence of “black holes”.

   However, the email doesn't attempt to identify the issue relative to
the existing specification.  The email goes on to propose to define a
concrete module system for Java that will have a fully specified syntax,
a module membership model, and provide consistent and predictable
visibility rules for dependencies. I would suggest that the efficient
use of time would be to identify clearly how the existing spec. fails in
these regards through specific references to existing documentation.
What we don't need is a construction of competing camps which would only
serve to divide effort and fracture the process - and I know we all
would agree that that is not your objective.

2. The email refers to 'drop-in' module systems.

   This subject is potentially broader but before engaging in this
subject we need to consider three possible architecture.  I have listed
three possible architectural strategies below.  The first strategy seems
to me to be the strategy followed by the Jigsaw implementation.  The
second strategy appears to me to be the orientation implied in you
email.  The third is my opinion something that covers the functional
requirements of both while enabling broad freedom for future evolution.

   Consider the following three solution architectures:

   a) a reference implementation
   b) a replaceable module sub-system strategy
   c) a binding of a module controller to a given module

   In the case of solution (a) we have an OpenJDK project call Jigsaw
which is building an implementation of a simple module system that deals
with both backward compatibility and forward modularisation aimed for
the most part and rationalising the management of deployment units
within the JVM code-base, while also providing an improved deployment
model to virtual machine consumers.  We should also note that once
included with Java 7, Jigsaw become a de facto reference implementation
and together with specifications in 294 will propagate to other virtual
machine implementations.  Also important to note is that alternative
module systems (all of which run above the JVM) will continue to operate
above the JVM.

  The second solution (b) would be something akin the the Java Logging
API and plugin-in replacement capability - enabled by system extensions
and a runtime API.  This strategy seems to be the model in the minds of
the authors of the email.  Clearly, such a strategy would require more
rigour in the interface definition - things like inclusion of the
specification of version ordering semantics in the spec. an SPI dealing
with delegation from core APIs to a provider module implementation.
Clearly such a solution would enable and foster a market for better,
smart, faster module solutions but at the end of the day - all this is
is a micro-level adjustment to the playing field (your favourite module
system is running as as the bootstrap module system as opposed to
running above the de factor module system).

   A strategy that combines both the desires of (a) and the interests of
(b) is the third alternative (c).  In this scenario we recognise that
there is one and only one system modularity implementation that is
dealing with the concern of modularisation of the JDK platform, but
also, we add an ability for the system module implementation to delegate
modularity management to a custom module controller based on
declarations with a given target module.  This would require that module
meta-data include an optional declaration of a controller module, that a
module controller API be defined, and that the system de facto
implementation handle the loading of module controllers and subsequent
delegation of module operations on a per-module basis.

3. The email refers to a subset of Jigsaw and OSGI as a datum.

   One should recognise that there are providers of module systems out
there that may take offence to a suggestion that the subset of Jigsaw
and OSGI is representative of the operational requirements and even
best-practices in the domain of Java modularity.  I would suggest that
29 references to OSGI is one email is symptomatic of a failure to
identify functional variation, and a fall-back to positioning to the
camp mentality and all of the divisive behaviour that could introduce. I
would suggest that we can be better than that.  I would suggest that we
can raise issues where issues exist, we can be strict in our analysis,
we can be specific in our arguments, and we can be constructive in our
solutions.

Cheers, Steve.


On Fri, 2009-08-14 at 10:48 -0600, BJ Hargrave wrote:
> Please find attached a proposal for a simple module system for Java.
> You will have to excuse the formatting done by my e-mail client. I
> have attached an html file which provides better formatting of the
> proposal. 
>   


-- 
Stephen J. McConnell
mailto:mcconnell at dpml.net
http://www.dpml.net
mobile: +61 4 5800 3980