RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

[Remi Forax]

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> À: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero" <vromero at openjdk.java.net>, "compiler-dev"
> <compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
> <hotspot-dev at openjdk.java.net>
> Envoyé: Mardi 24 Novembre 2020 02:04:55
> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

> Hi Harold,
> 
> On 24/11/2020 6:27 am, Harold Seigel wrote:
>> Hi David,
>> 
>> Thanks for looking at this.
>> 
>> The intent was for method Class.permittedSubclasses() to be implemented
>> similarly to Class.getNestMembers().  Are you suggesting that a security
>> manager check be added to permittedSubclasses() similar to the security
>> manager check in getNestMembers()?
> 
> No I'm suggesting the change to the API is plain wrong. :) Please see
> discussion in the CSR.

Given that the CSR is closed, i will answer here.
There are two issues with the previous implementation of permittedSubclasses, first it's the only method that using method desc which means that people has to be aware on another non trivial concept (object that describes constant pool constant) to understand how to use the method then i've tested this API with my students, all but one what able to correctly derives the Class from a ClassDesc, so instead of asking every users of permittedSubclasses to go through the oops of getting Class from a ClassDesc, i think we can agree that it's better to move the burden from the user to the JDK implementors.

> 
> Cheers,
> David

regards,
Rémi

> 
>> Thanks, Harold
>> 
>> On 11/18/2020 12:31 AM, David Holmes wrote:
>>> Hi Vincente,
>>>
>>> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>>>> Please review the code for the second iteration of sealed classes. In
>>>> this iteration we are:
>>>>
>>>> - Enhancing narrowing reference conversion to allow for stricter
>>>> checking of cast conversions with respect to sealed type hierarchies.
>>>> - Also local classes are not considered when determining implicitly
>>>> declared permitted direct subclasses of a sealed class or sealed
>>>> interface
>>>
>>> The major change here seems to be that getPermittedSubclasses() now
>>> returns actual Class objects instead of ClassDesc. My recollection
>>> from earlier discussions here was that the use of ClassDesc was very
>>> deliberate as the permitted subclasses may not actually exist and
>>> there may be security concerns with returning them!
>>>
>>> Cheers,
>>> David
>>> -----
>>>
>>>> -------------
>>>>
>>>> Commit messages:
>>>>   - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>>>
>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>>>>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>>>>    Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>>>>    Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>>>>    Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>>>>    Fetch: git fetch https://git.openjdk.java.net/jdk
>>>> pull/1227/head:pull/1227
>>>>
>>>> PR: https://git.openjdk.java.net/jdk/pull/1227