[jsr294-modularity-eg] Pain
Alex Buckley
Alex.Buckley at Sun.COM
Mon Aug 10 13:24:21 EDT 2009
Peter Kriens wrote:
> I've tried hard to distinguish between "namespace" modules and
> "deployment" modules. As you can see this gives "module" two meanings.
> To distinguish between these two cases, I decided to use container for a
> deployment module, if there are better names, let me know.
>
> Namespace modules are basically like packages, but making module
> membership hierarchical. This is a very natural model that I think is
> instantly recognized by all Java programmers. Containers are having
> dependencies and membership is based on containment in a physical
> artifact, allowing the membership (and visibility) to be defined in a
> packaging step.
>
> Unfortunately, 294 never had a crisp definition of a module so it is
> hard to describe a delta ...
I'm sorry but you're wrong. I defined a module for this JSR in January:
"A module is a named set of packages that a) defines an encapsulation
boundary for its member types, b) describes its relationships with other
named modules, and c) enforces both encapsulation and relationships at
compile-time and runtime. A module is identified by a name and
optionally a version."
-http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-January/000187.html
The whole point was to introduce a single concept for both accessibility
and visibility. I understand you want two concepts, which would be more
expressive, but also more complicated as I outlined in mails up-thread.
JSR 294 will not be introducing hierarchical namespaces for
accessibility in the Java language. JSR 294 will be introducing a single
module concept, akin to your 'container', that governs accessibility and
visibility. Thank you for your understanding.
Alex
More information about the jsr294-modularity-observer
mailing list