[sealed] Module & package constraints

[Dan Smith]

> On Apr 24, 2020, at 1:35 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> if the child and parent must successfully refer to each other, then we've already guaranteed that they're compiled at the same time. Is there something more to be gained from forcing them into the same package?
> But have we?  Imagine two packages, A and B, in separate maintenance domains.  First we have:
> 
>     package a;
>     interface I { }
> 
>     package b;
>     class C implements a.I { }
> 
> We can compile A, and then compile B against A.jar.
> 
> Now modify A, and recompile with B.jar on the classpath:
> 
>     package a;
>     sealed interface I permits b.C { }
> 
> This is fine.  Thereafter, these JARs can be recompiled independently.  And I could easily imagine lore surrounding this trick growing up as a "workaround" against the "stupid rule."

Okay, so not compiled at the same time, because the bottom-up half of the mutual reference can exist independently of the top-down half.

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.

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