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

[forax at univ-mlv.fr]

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "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 13:16:39
> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

> Hi Remi,
> 
> On 24/11/2020 7:45 pm, Remi Forax wrote:
>> ----- 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.
> 
> Why is the objective to get the Class objects? What purpose does that
> serve?

The whole idea of the reflection is to provide the runtime view of Java the language.
Even if such thing does not exist.

> The original API provided a descriptor for the contents of the
> permittedSubclasses attribute. I find it totally bizarre to have an API
> whose role is now to attempt to load all the subclasses of a sealed class.

It's as bizarre as Class.getClasses() loading all the member classes.

You are discovering that the reflection API is bizarre, and it is :)
It's not the view of the JVM, it's the view of Java at runtime, whatever it means.

> 
> YMMV.
> 
> David

Rémi

[1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Class.html#getClasses()

> 
>>>
>>> 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