[jsr294-modularity-eg] Nested superpackages

[Michal Cierniak]

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
nested superpackages.

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.

Michal

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.
>
> Andreas.
>
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>