[sealed] Module & package constraints

[Brian Goetz]

> But: if 'I' must be compiled with 'C' on its class path, and 'C' must be compiled with 'I' on its class path, isn't that effectively one maintenance domain? Practically, the only way the maintainer of 'I' is going to be able to declare a module is if they include 'C' in that module, too.

This is analogous to the statement that "cyclic module dependencies are 
effectively one module."  Which is eminently true, and yet many 
developers refuse to see it, and in fact see cyclic dependencies as an 
important missing feature in the module system.  Which means that 
dealing with situations like this has already become a part of the body 
of "tolerated programming practices."

That's not to say that we should always be in the business of stamping 
out bad practices, but this is a new feature and thus our one chance to 
set things rolling in the right direction.

> (I can kind of see a counter-argument that the compiler rule is designed to prevent this unwanted tight coupling by demanding that the classes belong to the same package. But it seems unrealistic that a programmer would succeed in *adding* a dependency on b.jar to their system, just to support a 'sealed' declaration. More likely, the dependency was already there for deeper reasons, which would have to be grappled with anyway to migrate to modules.)

And code that meets those "deeper reasons" will likely never 
modularize.  But, I would also rather not give them one more excuse why 
they can't....