> On Apr 24, 2020, at 1:35 PM, Brian Goetz <brian.go...@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.)
