On 24/11/2020 11:56 pm, fo...@univ-mlv.fr wrote:
----- Mail original -----
De: "David Holmes" <david.hol...@oracle.com>
À: "Remi Forax" <fo...@univ-mlv.fr>
Cc: "Harold David Seigel" <harold.sei...@oracle.com>, "Vicente Romero"
<vrom...@openjdk.java.net>, "compiler-dev"
<compiler-...@openjdk.java.net>, "core-libs-dev" <core-libs-dev@openjdk.java.net>,
"hotspot-dev"
<hotspot-...@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.hol...@oracle.com>
À: "Harold David Seigel" <harold.sei...@oracle.com>, "Vicente Romero"
<vrom...@openjdk.java.net>, "compiler-dev"
<compiler-...@openjdk.java.net>, "core-libs-dev"
<core-libs-dev@openjdk.java.net>, "hotspot-dev"
<hotspot-...@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.
And providing some kind of descriptor for an attribute fulfills that
role. Nothing says it has to produce Class objects.
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.
Not at all. Nested types are considered to be part of the same
implementation as the outer type. They are intimately related and all
part of the same accessibility domain.
Loading subtypes that likely exist outside of the current package (else
why would you need to be using sealed types) is a completely different
matter.
You are discovering that the reflection API is bizarre, and it is :)
I don't find it that bizarre.
It's not the view of the JVM, it's the view of Java at runtime, whatever it
means.
It means whatever we implement it to mean. So if we implement it in
bizarre ways then it will be perceived as bizarre.
David
-----
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
