[jsr294-modularity-eg] Nested superpackages

Bryan Atsatt bryan.atsatt at oracle.com
Fri Apr 27 12:56:17 EDT 2007 

Yep.

And imagine being asked by some development team if they should use 
nested superpackages. My response would be "no, split the project into 
modules first, then maybe consider nested superpackages".

We want to strongly encourage modularity. If the module system supports 
some form of access control to limit which modules can import another, 
you have the functional equivalent of nested superpackages.

And then my response would simply be "no, split the project into modules".

This feature may be useful in the short term for teams that cannot yet 
move to modules. But I strongly suspect that in the long term it will be 
seen as a mostly useless feature...

// Bryan

Glyn Normington wrote:
> 
> Of course I agree entirely with Bryan's perspective as that was pretty 
> much what I was thinking.
> 
> Another angle is that I believe nested superpackages should be omitted 
> from JSR 294 for Java 7 and added later if there is "customer" demand. 
> KISS and YAGNI. ;-)
> 
> Glyn
> 
> *Bryan Atsatt <bryan.atsatt at oracle.com>* wrote on 27/04/2007 03:09:47:
> 
>  > My intuition is that the complexity is not worth the benefit.
>  >
>  > I've consulted with hundreds of Java developers throughout both Oracle
>  > and our customer base, primarily regarding class
>  > loading/visibility/accessibility issues, and I strongly suspect that
>  > very few would even consider using nested superpackages. Any use of them
>  > forces most/all participants on that "large" team to understand the
>  > implications, and this feature is just a bit too subtle for many
>  > developers, IMO.
>  >
>  > With the C++ friend, the relationship between the classes is very direct
>  > and obvious (but far more restrictive, of course). With superpackages,
>  > it will no longer be obvious just from looking at a public class just
>  > who can access it. To me, the extra cognitive load is worth it for
>  > defining external contracts, but not for internal ones.
>  >
>  > I certainly see how I *might* use this feature in our (very large)
>  > system, but the sad truth is that the fear of the internal fallout more
>  > than offsets the perceived benefit.
>  >
>  > <historical-but-maybe-relevant>
>  >
>  > I was part of a 400 person team back in the early 90's creating a new OS
>  > from the metal up. It was entirely OO, unicode based, made heavy use of
>  > advanced language features, and pushed the state of the art in OO API
>  > and framework design. While *we* all "got it", five years, 1000's of
>  > APIs and 100s of frameworks later we ultimately learned that many
>  > "average" developers just could not understand it, or see how wonderful
>  > it all was :^). And really, it was. But it was a lesson I've taken to
>  > heart...
>  >
>  > </historical-but-maybe-relevant>
>  >
>  > Whenever possible, KISS.
>  >
>  > // Bryan
>  >
>  > Michal Cierniak wrote:
>  > > 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
>  > >>
>  > > _______________________________________________
>  > > jsr294-modularity-eg mailing list
>  > > jsr294-modularity-eg at cs.oswego.edu
>  > > http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>  > _______________________________________________
>  > jsr294-modularity-eg mailing list
>  > jsr294-modularity-eg at cs.oswego.edu
>  > http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
> 
> 
> 
> ------------------------------------------------------------------------
> 
> /
> /
> 
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg

More information about the jsr294-modularity-eg mailing list