Experience with sealed classes & the "same package" rule

[Maurizio Cimadamore]

On 24/06/2021 01:25, Dan Smith wrote:
> Under (2), I've violated the "single maintenance domain" assumption, but... when I run with foo.jar and bar.jar on the class path, everything works just fine. I've manually introduced an explicit dependency from foo.jar on bar.jar at compile time, which seems like a stupid thing to do, but sealed classes don't seem any more problematic in this regard than mutually recursive method signatures, etc.
>
> As John noted, the JVM doesn't care about any of this and enforces its own rules.

VM-wise, I tend to agree that this looks far less problematic.

Language-wise I was worried about checks for exhaustiveness - but then I 
was reminded of the fact that a sealed hierarchy has a list of 
"permits". So it's not like you can keep springing up new implementation 
into existence - if A permits B and C, well, there are only two classes, 
namely B and C, _somewhere_ in the classpath, with the usual 
implications of using classpaths - e.g. that the order in which jars are 
added to the classpath might affect what "B" and "C" truly are - but I 
agree, nothing new under the sun here.

Where this might run into problems is in cases where the language infers 
the permits list, which is something that was considered at one point. 
Of course doing inference in a world where things are not compiled all 
at the same time starts becoming problematic pretty quickly.

Maurizio