[sealed] Module & package constraints
brian.goetz at oracle.com
Fri Apr 24 20:09:28 UTC 2020
> 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
More information about the amber-spec-experts