[jsr294-modularity-eg] Nested superpackages

[Bryan Atsatt]

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