[sealed-types] Draft Spec for JEP 360 Sealed Types (Preview)

[Gavin Bierman]

There has been a small change to the spec available at:

	http://cr.openjdk.java.net/~gbierman/jep360/latest/ <http://cr.openjdk.java.net/~gbierman/jep360/latest/>

[This brings the spec in line with the compiler on the corner-case of an enum class that both implements a sealed interface and contains an enum constant with a class body.]

Thanks,
Gavin

> On 6 May 2020, at 16:13, Gavin Bierman <gavin.bierman at oracle.com> wrote:
> 
> We have made some presentational changes to the spec for JEP360 (Sealed Types), which are available at:
> 
> 	http://cr.openjdk.java.net/~gbierman/jep360/latest/
> 
> The only semantic change is a new error if the direct superclass or direct superinterface of a local class is `sealed`. A more complete set of changes to address all interactions between local and member classes and sealed types (see [1] for some of these) will come later, although perhaps not until JDK 16. 
> 
> Thanks,
> Gavin
> 
> [1] http://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-May/002156.html
> 
> 
> 
>> On 20 Apr 2020, at 22:50, Gavin Bierman <gavin.bierman at oracle.com> wrote:
>> 
>> The latest (and hopefully final) draft of JEP 360 (Sealed Types) is available at:
>> 
>>   http://cr.openjdk.java.net/~gbierman/jep360/latest
>> 
>> The changes since the last draft was circulated in February [1]:
>> 
>> * Some minor typos have been corrected, including changing the title of 8.1.6.
>> 
>> * We have make corrections in a number of places to make it clear that the name
>> in a `permits` clause is not a type (and can not be annotated, for example).
>> 
>> * We now require a functional interface to not be `sealed`, rather than imposing
>> checks on target types of lambda expressions. 
>> 
>> * We have removed the changes to narrowing reference conversion which allowed
>> for stricter checking of cast conversions wrt sealed type hierarchies. We have
>> decided to defer this feature until a later release to allow us to develop a
>> broader treatment of "disjoint types" that can be used not just in cast
>> conversion, but in other places such as bounds checking and pattern matching.
>> 
>> The refined cast conversion was nice to have, but really only will make a
>> difference when we get to patterns in switches, so it makes sense to spend some
>> more time now considering our design rather than refining cast conversion in a
>> piecewise manner. 
>> 
>> Thanks,
>> Gavin
>> 
>> [1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-February/002031.html
>> 
>