I fixed a number of small bugs in the spec. The latest draft is available at:
<http://cr.openjdk.java.net/~gbierman/jep360/latest/>http://cr.openjdk.java.net/~gbierman/jep360/latest/
<http://cr.openjdk.java.net/~gbierman/jep360/latest/>
Thanks,
Gavin
> On 13 May 2020, at 17:34, Gavin Bierman <gavin.bier...@oracle.com> wrote:
>
> 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.bier...@oracle.com
>> <mailto:gavin.bier...@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/
>> <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.bier...@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
>>>
>>
>
