[jsr294-modularity-eg] Nested superpackages

[Andreas Sterbenz]

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.