[jsr294-modularity-eg] Nested superpackages
Andreas.Sterbenz at Sun.COM
Thu May 3 02:59:10 EDT 2007
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.
More information about the jsr294-modularity-eg