Java and security bits

Nested Superpackages Restated

A few weeks ago I posted an entry that explained what superpackages are about. This is a continuation that deals with nested superpackages. If you have not read the first post, read it before continuing. As a reminder, the short version is: a superpackage is a language construct for information hiding [1].

With that in mind, let us explore what a nested superpackage is: a nested superpackage is a superpackage contained within another superpackage. Since a nested superpackage is still a superpackage, what I said about top level superpackages also applies to nested superpackages. In other words, a nested superpackage is a language construct for information hiding.

Let's look at what this definition says about what a nested superpackage is not: it is not a namespace construct. The Java source language does not recognize multiple types of the same fully qualified name today. Adding new access control mechanisms does not change that. Of course, the other things I mentioned which a superpackage is not also still apply: no changes to the type system or to the way you package your applications.

That states what nested superpackages are and what they are not, but it does not explain why they are useful. But that is pretty simply: they are an access control mechanism and as such allow you to separate code within one project (i.e. one top level superpackage) and to hide implementation details. A way to visualize it is to imagine a bubble representing your project and floating within it all your classes and interfaces. Often you will want to organize those classes into subsystems - a bubble within the bubble. If a subsystem is too large for a single package, you need something else. That is where nested superpackages come in. One example of a project where this structure will be very useful is the core of the JDK, as I explained in this message to the JSR 294 expert group, but there are certainly many other projects with similar needs.

The final thing to say about nested superpackages is that (as described above) they are a way to organize the internals of a component, not a way to aggregate code from multiple components. You would use a deployment module solution such as JSR 277 to do that. The guidance is that if a subsystem is tightly coupled with the rest of a project, it should be a nested superpackage. If it is effectively an independent unit and reusable, it should be its own component as a top level superpackage. Other components can import it using JSR 277. The distinction may seem arbitrary and impossible to make, but it is not much different than deciding whether to organize your code into one, two, or more packages. With a bit of experience, it comes natural to developers.

That was quite a bit of text, but the one thing to remember is that a nested superpackage is a superpackage contained within another superpackage. In other words, a nested superpackage is a language construct for information hiding. Really. Nothing more to it than that.

[1] If you don't like the term information hiding just replace it with access control in this entry. In this context it is a good approximation as information hiding is the concept and access control the mechanism to implement it.

Posted at 11:20 May 30, 2007 by Andreas Sterbenz in Modularity  |