peter.kriens at aqute.biz
Mon Aug 10 03:13:55 EDT 2009
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
Unfortunately, 294 never had a crisp definition of a module so it is
hard to describe a delta ...
Hope this helps. Kind regards,
On 31 jul 2009, at 17:58, Stephen J. McConnell wrote:
> On Fri, 2009-07-31 at 15:28 +0200, Peter Kriens wrote:
>> I tried very carefully not to define how class loaders going to
>> operate in runtime. However, modularity in Java introduces attributes
>> that are associated with the aggregate of class files/compilation
>> units. This aggregate I called the container and I do think it needs
>> to defined as a concept in the JLS and not shoehorned in a
> OK - I'm not getting the problem.
> I would agree that 'modularity in Java introduces attributes that are
> associated with the aggregate of class files/compilation units'. I
> would have referred to that as a module. You want to referer to
> that as
> a container. Can you explain relative to the existing 294 notion of
> module exactly what changes you feel would be beneficial and what the
> supporting arguments are that differentiate 'module' from your
> notion of
> Cheers, Steve.
> I have a particular interest in 'containers' and how an emerging
> 'module' solution play together.
> Stephen J. McConnell
> mailto:mcconnell at dpml.net
> mobile: 04 5800 3980
More information about the jsr294-modularity-observer