[jsr294-modularity-eg] Nested superpackages

[Glyn Normington]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070427/a45df0ef/attachment.html