[jsr294-modularity-eg] Nested superpackages
cierniak at google.com
Thu Apr 26 12:52:46 EDT 2007
I agree with the points made by Andreas below. If some code is made
to be reused multiple times, it should be considered a unit of
deployment and modularized appropriately.
OTOH, the ability to structure things within a module in a relatively
lightweight manner but with better semantics than those of Java
packages is a good thing in my opinion, so I support the notion of
At the same I must admit that Glyn's argument that the benefit must
outweigh the cost of extra complexity should be taken by us seriously.
I have struggled with the same argument and I am very sympathetic
with his point of view. However after thinking about it for a while,
I concluded that for me the benefits are significant enough that we
should have this feature.
I think that we all go here a bit by our intuition and it will be hard
for anyone to provide hard evidence one way or the other until
developers start to use superpackages.
On 4/26/07, Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote:
> 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.
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-eg