[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