Experience with sealed classes & the "same package" rule

forax at univ-mlv.fr forax at univ-mlv.fr
Wed Jun 23 09:50:52 UTC 2021

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>, "daniel smith" <daniel.smith at oracle.com>,
> "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 23 Juin 2021 04:35:06
> Objet: Re: Experience with sealed classes & the "same package" rule

> On Jun 22, 2021, at 2: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.
>> We can save a lot of test and debugging time to a lot of people by avoiding
>> split sealed hierarchy.
> Nah.  The JVM (and probably javac) has to check
> for broken inputs always, regardless of how
> likely those broken inputs might be.

The OpenJDK is rich in term of engineering hours, i was thinking more about the other tools that consume the source file and the class file that are not in such position of privilege.


More information about the amber-spec-experts mailing list