Superpackage: OSGi in Disguise?

Some information is starting to drip out from SUN about their modularity plans. While planning my JavaOne schedule I ran into session TS-3885 Superpackages: Development Modules in Dolphin. Obviously this raised my interested and after some googling I found a blog by Bracha describing superpackages.

A superpackage is a declaration of a module that consists of Java packages. For example:

  super package com.acme.system {
    export com.acme.p.*;
    export com.acme.q;
    com.acme.private;
  }

Interestingly, Gilad Bracha spents a number of paragraphs telling us not to complain about the (obviously deficient) syntax. Forget the syntax, I can even forgive him for lacking most details. However, he does not even explain where the superpackage source will reside and how it will be used during development. Will it be part of the Java source files? Will it be a new source file that resides in a package? Will it be linked from Java source files, like an import statement? Will it be a separate artifact? How will it interact with the existing artifacts? The usage of an artifact is a pretty fundamental aspect of a module architecture because it has extensive implications.

So let us explore, what are the options? Making the superpackage definition part of the source file will of course create redundancy. This redundancy can be minimized by referring to the artifact from a source file. However, this implies that a source file is bound to a module and can never be part of two different modules. In real life, there are often situations where multiple artifacts must be created from the same constituents. Think for example about Java Profiles, but also SWT is delivered in an embedded version and a desktop version. It is therefore just plain wrong to assume that a source file is always part of the same module.

The only useful solution seems to be placing the superpackage artifact at a special place and link to it from the sources. However, the compiler will need to be able to find it somehow when it compiles a source file. The compiler could be instructed with a special directive but that sounds pretty unworkable and error prone. I can only think of one more place to put this superpackage artifact: The packaging unit of the class files; today this is usually the JAR file.

Such a model allows the creation of different superpackages for different purposes. It is easy to find by the compiler and it is also very useful for deployments.

Now, why does this model feels so familiar? Hmm, maybe this is because it is exactly the way the OSGi specifications do it. The superpackage artifact is basically our manifest header. Though information about superpackages is sparse in the blog, the implied semantics are a (small) subset of the OSGi specifications. Gilad Bracha says that OSGi is only about deployment but this is obviously no true. The Eclipse compiler uses the OSGi manifest header to provide proper modularization on source level.

Maybe superpackages are simpler than OSGi headers? Don?t think so, from what I have seen so far the superpackages just look simple because they have not even been well defined yet, let alone used in real life applications. We did not add versioning because we thought it was fun. Versions are an intrinsic part of modularization. The uses directive was not someone?s cool idea, but we had real life use cases that could not be solved without it. Custom attributes are not a joke but are a necessity for some complex systems.

Superpackages sound like a dangerous idea for the Java language. They complicate the basic language in a polluted way while not providing any benefit that is not already available with JSR 291/OSGi. An existing solution that is backward compatible and does not require unnecessary language extensions. The OSGi specifications are not language intrusive and have the benefit of 7 years of experience. Do Superpackages look like a clear case of the not invented here syndrome?

   Peter Kriens

posted by Peter @ Monday, April 10, 2006