[jsr294-modularity-eg] Nested superpackages

Andreas Sterbenz Andreas.Sterbenz at Sun.COM
Thu Apr 26 03:27:29 EDT 2007


Eugene Vigdorchik wrote:
> Nice explanation, Andreas. Still what happens if a superpackage is
> nested in more than one enclosing superpackage? As far as I understand,
> several deployment units may exist that will each include the classes
> from nested superpackage.While Strawman says: "it is expected that a
> superpackage and all its nested superpackages will form one deployment
> unit", it could be more specific to say that classes from nested 
> superpackages could be included in other deployment units as well or
> form a separate deployment unit by themselves.

A superpackage cannot be nested in more than one enclosing superpackage. 
Let me explain.

It is useful to think of a top level superpackage as one unit. Although it 
is internally structured into packages and/or nested superpackages, they 
are not meant to be detached from the enclosing superpackage.

As a bad analogy, think of a nested class and its enclosing class. The 
nested class cannot live on its own. The same goes for a nested 
superpackage, which is nested within one particular superpackage. It 
should not be moved elsewhere or distributed on its own.

What you seem to suggest is that you would like some piece of code X to be 
be a reusable component that can referenced from several different places. 
If that is the case, X is a use case for deployment modules (i.e. JSR 277, 
OSGi, etc.) and well addressed by those solutions. In other words, X would 
become a top level superpackage packaged using the appropriate deployment 
solution, and then referenced as a dependency by other deployment modules.

Nested superpackage have a different goal, which is information hiding 
between subsystems within a project.

Andreas.



More information about the jsr294-modularity-eg mailing list