JSR 294 is a proposal to add superpackages to the java language. I’ve been observing the discussion on the public mailing list, and I’ve thought about the proposals. Finally I’ve decided to voice my concerns about the current discussion:
The current proposal seems conceptually with its support of nested superpackages overly complex. As I understand it, every superpackage can have a tree-like hierarchical substructure of nested superpackages, which are almost, but not quite superpackages.
On the other hand, there is a call to eliminate nested superpackages, which would not meet the use case where a package would have a separate, but private support package.
Wouldn’t it be more useful (and simultaneously conceptually simpler) if every superpackage could explicitly restrict the set of superpackages that are allowed to import it?
On that thought, the jsr proposal calls for a solution for the problem of ‘designers are forced to declare elements of the program that are needed by other subparts of the implementation as public - thereby making them globally accessible, which is clearly suboptimal’. And it is clearly a worthy goal to achieve that (at least to me).
Maybe I sound like a heretic for just suggesting this, but maybe, superpackages are the wrong solution. Today, (almost) all java software is divided into packages, and multiple of those packages are packed together in jar files. What if each package could specify (via package.java), which other packages are allowed to import it? As I see it, this approach would have several advantages:
Maybe the expert group has already discussed this and decided in favor of the superpackage proposal, but I could not find any mention of this in the mailings sent to the mailing list. As an avid java programmer I am concerned about the direction the discussion seems to be taken, and I felt that I had to at least mention this possibility.