JEP-360 Sealed types and non-accessible subtypes

[Kłeczek, Michał]

On 01/12/2019 18:33:40, "Remi Forax" <forax at univ-mlv.fr> wrote:
>
>>  I have just realized permits clause is in fact optional. Optionality is
>>  though only a syntactic sugar to save some keystrokes.
>>  I think it might be useful to change its semantics to mean any type in
>>  the same module and not just the compilation unit.
>
>i've hard time to understand what your are suggesting:
>- is it, if a sealed interface need to be compile then all files in the module need to be recompile ?
>- or is it if a class inside a module is changed, because we don't know if there is a sealed interface in it or not, we need to recompile the whole module ?
>
>In both cases, is it not equivalent to say that you can not compile a module incrementally anymore ?
I am not sure I understand the second case. What I suggest is

public sealed interface A {}

would mean only types in the same module as A can implement/extend it.
Generated class file does not need to contain any list of permitted 
subtypes
- having an empty set means "any in the same module".

I thinke we have the following cases:
a) change sealed type to non-sealed
Obviously non-issue
b) change non-sealed type to sealed
Does not affect existing classes in the same module (as they can 
subclass anyway)
c) change a type to be a subtype of a sealed type
Does not affect the sealed supertype.

In general marking a type as sealed (without permits clause) would only 
require both the compiler and the verifier
to check any class for being in the same module if any of its supertypes 
is sealed.

Thanks,
Michal