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....
