RFR: JEP 360: Sealed Types (Preview)

[Remi Forax]

About the JEP text,

It's not clear to me if "compilers" in the sentence "The lack of documented exhaustiveness also prevents compilers from being able to do exhaustiveness analysis."
refers to java compiler or JIT compilers. Obviously the answer is both :)

The example of "rotate" is a weird example, currently there is no exhaustiveness analysis on a switch statement
(we have decided that backward compatibility was more important than exhaustiveness, something i'm already regretting).
Or worst does it mean that switch on Object will do exhaustiveness analysis while switch on enum don't ?

cheers,
Rémi

----- Mail original -----
> De: "Vicente Romero" <vicente.romero at oracle.com>
> À: "amber-dev" <amber-dev at openjdk.java.net>, "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoyé: Lundi 13 Avril 2020 18:03:18
> Objet: RFR: JEP 360: Sealed Types (Preview)

> Hi all,
> 
> The sealed types JEP was already reviewed a while back when we were
> planning to include it in JDK14. It finally fell off that boat but it is
> being considered now for JDK15. There have been some changes since then
> mostly related to subtypes of a sealed type. Before we were planning to
> infer finality, sealness or non-sealness in the subtypes. We steered
> away from that direction in favor of explicit declaration at the
> subtype. I would like to ask for another review of the current version
> of the JEP that reflects these changes. The JEP is at [1] and the last
> version of the spec is at [2],
> 
> Thanks,
> Vicente
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8227043
> [2]
> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200228/specs/sealed-types-jls.html