[jsr294-modularity-eg] Nested superpackages

[Glyn Normington]

LUNI is a great example as it has distinct subcomponents that use each 
other's implementations.  Even the Harmony project, which was effectively 
starting with a clean slate, decided to put LUNI in a single bundle ([1]). 
We shouldn't think that the close coupling of the subcomponents is an 
implementation choice or just a legacy - it's more of a design constraint 
inherited from the spec.

JSR 291 offers a solution in the form of "host" and "fragment" bundles 
which are distinct deployment modules that are merged into a single 
logical module (with a single class loader) at runtime. Such deployment 
modules can share internals without exporting them to other (logical) 
modules. However, not all module systems have that kind of feature - JSR 
277 doesn't for example.

So if we really want JSR 294 to address the requirement exemplified by 
LUNI, should we not see whether there is a better information hiding 
approach than the current nested superpackage proposal? For instance, has 
class name prefixing being considered, along the same lines that were used 
for nested classes to prevent unexported classes clashing unexpectedly?

Glyn
[1] 
http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/luni/META-INF/MANIFEST.MF?view=markup

Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 03/05/2007 07:59:10:

> Glyn Normington wrote:
> > 
> > Yes, I can see the theoretical justification for a nested superpackage 

> > construct. I'm just struggling to understand its practical usefulness 
in 
> > large projects given that deployment modules give a clean way of 
> > dividing up a large project which prevents unexpected version clashes. 

> > I'd be interested in feedback from the community observing this list.
> 
> A simple example where nested superpackages are needed to express the 
> desired structure is part of the core of the JDK. I use that example 
> because I am very familiar with that code, but similar situations are 
> bound to exist in many other projects.
> 
> In the JDK some of the Core API packages java.lang, java.io, and 
java.util 
> are inherently tightly coupled, so they should be one unit. However, the 

> implementation details of e.g. the Reflection and IO implementation are 
> unrelated and should be separated from each other. In addition, all the 
> different parts of Core rely on the internal Misc classes, which should 
be 
> accessible to Lang, IO, and Util but not to any code outside the Core.
> 
> Nested superpackages allow us to express this structure in a 
> straightforward way. I create a superpackage Core with the exported 
nested 
> superpackages Lang, IO, and Util and the non-exported nested 
superpackage 
> Misc. A very simple partitioning of the subsystems.
> 
> Solutions without nesting cannot do that. Either I put all classes into 
> the Core module without nesting, in which case all public implementation 

> classes are accessible to all other Core classes. That means there is no 

> isolation between the subsystems.
> 
> The other alternative is to break up the Core unit into individual 
> modules: Lang, IO, Util, and Misc. That hides e.g. internal Lang classes 

> from IO classes, but it means that the exported Misc classes become 
> available to everyone and not just types in Lang, IO, and Util. In 
> addition, I have to expose the internal project structure to client 
> applications, which now see 4 modules instead of a single module.
> 
> Does this problem occur in all superpackages? No. But it will occur in 
> many somewhat larger and more complicated systems, which is where good 
> structure and information hiding is most important.
> 
> The bottom line is that either attempt to solve this issue without 
nested 
> superpackages results in incomplete information hiding - some 
> implementation classes become accessible. This is the problem JSR 294 
was 
> created to solve, so we need to address it. We can debate if the current 

> syntax for declaring nested superpackages is appropriate to capture the 
> intent, but delegating the problem to deployment modules or deferring 
the 
> problem to a future JSR is not a solution.
> 
> Andreas.
> _______________________________________________
> 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/20070504/47288b9d/attachment.html