[jsr294-modularity-eg] Simple Module System Proposal

[Stuart McCulloch]

2009/9/17 Stephen J. McConnell <mcconnell at dpml.net>

> On Tue, 2009-09-15 at 12:36 -0400, BJ Hargrave wrote:
>
> > The proposal does not mention many things :-) But its goal was to
> > define a meaningful starting point for modularity which is extendable
> > into more complex spaces like app servers which have a real and
> > genuine requirement for side-by-side versions.
> >
> > By neutering the proposal to use a single class loader, you make it
> > uninteresting for all but the most simple run-and-done applications.
> > And those simple applications don't need modularity anyway.
>
> BJ:
>
> Could you please explain your thinking here.
>
> As things currently stand [a.k.a. my understanding] the specifications
> of modularity (with 294) deals with the mechanisms through which a
> modularity boundary is defined, the composition of given module
> (classes, resources, and possibly exposure of other local modules), and
> the relationship to other foreign modules. The 294 process deals with
> the language, classfile, and virtual machine extensions and
> modifications required to achieve this.
>
> We then have a second subject concerning the the way in which modularity
> is realised during execution and this is turn is where classloaders
> emerge. If we look at Jigsaw as an example of an implementation of
> modularity, we have a framework that generally speaking provides a
> one-to-one mapping between modules and classloaders. I say generally,
> because the modularity language does provide for local modifier on
> dependency declarations (and through that mechanisms we have the
> possibility to introduce module-based decomposition of the JRE while
> preserving a final system classloader).
>
> It is also important to note that anything running above the VM that is
> expressed as a module will by default be deployed in a separate
> classloader and that dependent modules will be deployed in separate
> classloaders (excepting the case of an explicit local declaration).
>
> Based on your comment, I'm assume that you view the one-to-one mapping
> of module to classloader as too restrictive.  Is that correct, and if
> so, could you explain what issues you feel that this raises?
>

I thought BJ was in favour of the one-to-one mapping, quoting from an
earlier note in this thread:

   "From a convention over configuration point of view, it is very clear and
easy
    to specify that one artifact is one module and has one class loader"

his last comment was in response to Alex's suggestion of one classloader for
multiple modules

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

-- 
Cheers, Stuart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090917/93912ba4/attachment.html>