[sealed] Module & package constraints

[Johannes Kuhn]

The scenario I think about is the following:
a.Foo is in A.jar. It was never designed to be extended, but the 
maintainer made a mistake and forgot to restrict that (for example did 
not remove the default constructor).
b.Bar in B.jar extends a.Foo. This was a bad idea, and should not have 
been done in the first place.

The maintainer of A.jar decides to finally fix the mistake of a.Foo 
being extensible. But doing so would break the popular B.jar.
So they use a hack and add B.jar to the classpath, add sealed to a.Foo 
and explicitly permit b.Bar. (People will do stupid things)

Now the maintainer of B.jar comes around, notices that this class was 
never meant for extension in the first place, composition is better than 
inheritance...
But if they now remove the "extends a.Foo", their class won't compile 
anymore.

At this point, any solution becomes more messy.

Maybe I missed the small but important detail that both a.Foo and b.Bar 
has to be compiled at the same time from source code.
Then people would create a dummy "class Bar extends a.Foo {}" to get 
around that. (Also, incremental compilation?).

In my opinion, the mistake was to allow a.Foo to permit b.Bar.
And this would break if A.jar, B.jar or both are put on the module path.

So in my opinion, the requirement that both types are in the same 
package for the unnamed module *during compilation* must stay.

On 24-Apr-20 23:24, Dan Smith wrote:
> Sounds like the conclusion is:
>
>> On Apr 24, 2020, at 1:16 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>>
>> I presented this as an outline of our choices, but to put a stake in the ground, here are my preferences.
>>
>>> On Apr 23, 2020, at 12:27 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>>>
>>> 1) Is it legal to have a permitted subclass/subinterface that does not actually extend the permitting class or interface?
>> At compile time, no. Let's prohibit that.
>>
>> At run time, delay any validation until a particular subclass is loaded.
> Agreement on both of these. (Requires a new rule in the language spec.)
>
>>> 2) What are the constraints on module membership?
>> At compile time, do nothing. Per (1), it's already impossible to successfully declare a sealed parent/child across a module boundary.
>>
>> At run time, require the same run-time module. In the corner case of a parent/child split across class loaders (in unnamed modules), we say "sorry, don't do that." (I do think this will come up. Extension is an important way to communicate across class loader boundaries. But I think programs doing so need to accept that sealed types are not for them.)
> Agreement on both of these. (Language spec can mention the module implication, but doesn't need to make it a rule.)
>
>>> 3) What are the constraints on package membership?
>>>
>>> The use case here is a class/interface extending a sealed class/interface, both in the same unnamed module.
>> At compile time, do nothing. Per (1), it's impossible to separately compile the parent and child, no matter what packages they are declared in.
>>
>> At run time, there's nothing to enforce. I don't care how you've deployed your class files, as long as they successfully compiled and have the same module/loader.
> The compile-time package restriction should stay, as a nudge away from unwanted circularities.
>
> There's a choice to make at run time, with some disagreement. I think it makes sense to leave it out for now. (Only way to get into this situation is to generate bytecode with something other than javac. You can't get there with separate compilation.)