[jsr294-modularity-eg] Nested superpackages

[Andreas Sterbenz]

Glyn Normington wrote:
> 
> What do we really lose by deleting nested superpackages? In these 
> situations, my feeling is that "less is more" and deleting this feature 
> will strengthen the whole proposal.

Not having nested superpackages would mean instead of a project having a 
top level superpackage and a nested superpackage for each subsystem, all 
classes of the project would be a member of the top level superpackage. It 
could hide implementation details from code outside the superpackage by 
declaring such public classes as non-exported, but it would not be 
possible to isolate subsystems within the project from each other.

In particular, a class that is used by multiple packages of a subsystem 
would have to be a (non-exported) public class even if it is an 
implementation detail of the subsystem. That means it could accidentally 
be used by other subsystems within the project.

In other words, we have the same problem we have today with package based 
access control: it is not possible to hide implementation details as 
desired. Just as we currently have that issue for projects too large to be 
appropriate for a single package, we would have the same issue for 
projects that are too large to be appropriate for a single superpackage.

That means we would be addressing only part of the problem JSR 294 set out 
to solve. That is not the correct goal for us.

We should keep in mind that the added conceptual weight of nested 
superpackages is very low. They are not a concept distinct from 
superpackages, just a recursive application of the same idea. Nor do they 
complicate live for developers who prefer to stay with a flat system and 
not to use nesting.

Andreas.