On Friday, Andreas Sterbenz posted a strawman proposal for JSR 294, which has also been known as superpackages. The basic idea behind superpackages is that we need the ability to define a scoping mechanism bigger than the package that allows you to state which of those packages or classes are public, and which are not. This allows you to do things like define an API package that is mostly composed of interfaces and perhaps a factory class but also have a set of internal private packages that define the implementation and declare that as one superpackage. They also allow you to start building the infrastructure needed for a runtime deployment mechanism as defined in Java Modules (JSR 277).

This is something that I think would be really useful in practice. I’ve had some conversations with Neil Bartlett about this already regarding OSGi, because OSGi already fully supports the ability to define the public parts of a plugin. And while I agree that is good and useful, there are plenty of situations where I wanted to do something like this without depending on OSGi.

So anyways, the proposal as written seems like a fair starting point. I’m still thinking about the ramifications of nested superpackages and whether that is really necessary given the complexity it adds.

A few questions and comments:

1. A quick request on syntax – I know the syntax will evolve but it’s hard to tell from the examples whether the “member package” and “member superpackage” lines exist at most once or whether there can be many of these. I would certainly vote for not restricting this to a single line. Seems like that could get ugly real quick. I’d really want my IDE to automagically organize those just like they do my imports. Same thing on the exports
2. Superpackage nesting – It’s not stated but it seems like a superpackage can only have one enclosing superpackage?
3. Superpackage utilities – It’s stated that a Class will have a method to get its superpackage. Presumably the Superpackage class would also allow you to get its superpackage? Maybe it would be nice to have a utility method to get the chain of super-packages above a class? Just trying to imagine what tools would need to deal with the superpackage hierarchy.
4. Classloader definition – The line “A superpackage file is loaded via a ClassLoader. A superpackage is always defined by the same ClassLoader as its member classes.” scares me a little but maybe I’m reading too much into it. This implies to me that all classes in a superpackage (which may contain other superpackages) must be loaded by the same classloader and that seems like a hard constraint. Is this necessary from an implementation point of view?

Having worked on a lot of SCA stuff recently, I can also see some similarities in the problems that SCA has been working on with the problems being addressed in JSR 294, specifically to do with describing hierarchies and deployment of composite applications. I’m sure that are some aspects of the SCA Java Component Implementation that could make great use of JSR 294/277 at some future point.