Experience with sealed classes & the "same package" rule

[Remi Forax]

----- Mail original -----
> De: "daniel smith" <daniel.smith at oracle.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 9 Juin 2021 23:42:16
> Objet: Experience with sealed classes & the "same package" rule

> Here's some late feedback on the sealed classes preview. Probably actionable
> before 17 GA, if that's what people want to do, or potentially a change that
> can come in a future release. (Or you can just tell me that this inconvenience
> isn't a big deal, live with it.)
> 
> The spec for sealed classes contains this rule:
> 
> ---
> 
> If a sealed class C belongs to a named module, then every class named in the
> permits clause of the declaration of C must belong to the same module as C;
> otherwise a compile-time error occurs.
> 
> If a sealed class C belongs to an unnamed module, then every class named in the
> permits clause of the declaration of C must belong to the same package as C;
> otherwise a compile-time error occurs.
> 
>> Sealed class hierarchies are not intended to be declared across different
>> maintenance domains. Modules cannot depend on each other in a circular fashion,
>> yet a sealed class and its direct subclasses need to refer to each other in a
>> circular fashion (in permits and extends clauses, respectively). Necessarily,
>> therefore, a sealed class and its direct subclasses must co-exist in the same
>> module. In an unnamed module, a sealed class and its direct subclasses must
>> belong to the same package.
> 
> ---
> 
> A unique property of this rule is that it is guarded on whether code lives in a
> (named) module or not. If you're in a module, you get language semantics X; if
> not, you get language semantics Y. In particular, there exist programs that
> will compile when packaged in a module, but will not when left to the unnamed
> module. (This is different than the canonical use of modules, which is to
> restrict the set of packages that are observable, depending on the
> configuration of the current module.)
> 
> In practice, I had this experience:
> 
> 1) Trying to deploy some Java code with a tool that requires a single jar.
> 2) Need to include the experimental bytecode API, which is packaged as a module.
> 3) Copy the needed API sources into my own source tree.
> 4) Compilation fails: lots of "cannot extend a sealed class in a different
> package" errors.
> 
> Unfortunately, the bytecode API was making use of sealed classes, and those
> hierarchies crossed package boundaries. (In a typical public API vs. private
> implementation packaging strategy.)
> 
> (The workaround was to declare my own module-info.java and package my program as
> a single modular jar.)
> 
> Is this behavior consistent with the design of modules? I lean towards "no":
> Java sources don't opt in to modules. They belong to a module, or not,
> depending on the context—whether there's a module-info.java somewhere, which
> javac parameters are used. The sources themselves are meant to be portable. But
> this rule means any sealed class hierarchy that crosses package boundaries is
> asserting *in the program source* that the classes must belong to a module.


I don't follow you here, a module-info.java is part of the source, it ends with .java after all, so like any .java files if you don't copy them, the behavior of the library will change.

As an example independent of sealed types, if there is no module-info, packages are open, if there is a module-info, packages are not open.
Thus the behavior of a Java library change depending if there is a module-info or not.

So the fact that the behavior of sealed type change if there is a module-info or not, is consistent with the design of modules.


Sealed hierarchies are restricted to a package in the unamed module in order to ease the migration when you add a module-info because a sealed hierarchy restricted to a package is obviously restricted to a module.
If you relax that rule, you add another hindrance to the adoption of modules.

regards,
Rémi