Experience with sealed classes & the "same package" rule

[Dan Smith]

> On Jun 22, 2021, at 4:05 AM, Maurizio Cimadamore <Maurizio.Cimadamore at oracle.com> wrote:
> 
> I was working under the assumption that we would NOT just blindly allow different packages (e.g. in unnamed module) to access same sealed hierarchy in an uncontrolled fashion.
> 
> Without the natural boundary provided by modules, it seems like this would be problematic, and would essentially rely on the user "not trying too hard" (as Dan put it). So IMHO, the choice is between keeping the rules we have now, or backout the special rules around modules, and keeping all accesses to a sealed hierarchy package-confined. The middle ground seems murky and not strong enough, from a language perspective.

Yeah, to clarify: I was *not* suggesting that we should be more strict in module code. Cross-package type hierarchies are a useful feature! (One that we didn't invent when we created modules.)

My high-order complaint is that module source code can't be repackaged into an unnamed module, and this is something new in the language. My proposed resolution of this inconsistency is to be *less* strict, allowing cross-package extension in an unnamed module.

> On Jun 23, 2021, at 7:04 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> The rule is the tail; the dog is that "sealing is tight coupling, so sealed hierarchies should be co-maintained."  We don't have formal maintenance boundaries, but packages (for non-modular code) and modules (for modular code) are the closest approximation.  Bristling at the rule is really bristling at the fact that we don't have a formalized notion of maintenance domain.

I'm not really following the concern here. I understand discouraging "bad" usage of the feature, which is why, all things being equal, sure, why not have a rule where javac says "it looks like you're doing this wrong." But with those sorts of error checks, we want to err on the side of permissiveness—I can't tell for sure whether you're misusing the feature, so I'll let it go.

Another category of error check is when there's a mandatory invariant that must be enforced, even if it involves false positives or annoying guardrails. It's not clear to me why this error check would fall into that category.

Maybe a specific example could help?

Start with:

package foo;
class A {}

Compile to foo.jar.

package bar;
final class B extends foo.A {}

Compile with foo.jar on the classpath, get bar.jar.

Now refactor:
package foo;
sealed class A permits bar.B {}

Compile with bar.jar on the classpath. Either:
1) Error, "bar.B is in a different package"; or
2) Generate a revised foo.jar

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.

So: I'm not seeing a mandatory invariant that must be enforced, and that justifies erring on the side of false positives.

> On Jun 22, 2021, at 3:08 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> The proposed simplification allows different packages to share different part of the sealed hierarchy without a module.
> So those packages can be in different jars, compiled at different times.
> This will produce "impossible" sealed hierarchies where by example two types are both permitted subtypes of each other.

Class circularities are prohibited at both compile time and run time. Nothing new here.

Extra classes in a PermittedSubclasses attribute are harmless—the attribute only has the effect of rejecting a certain class if it claims to extend another but is not in the permitted list.

I'd love to have another achievable scenario of concern to think about (other than the one I outlined above), but I'm having trouble envisioning it.