getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc
Remi Forax
forax at univ-mlv.fr
Thu Nov 5 12:39:46 UTC 2020
> De: "Chris Hegarty" <chris.hegarty at oracle.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 5 Novembre 2020 12:18:27
> Objet: Re: getPermittedSubclasses() on j.l.rClass returning an array of
> ClassDesc
>> On 29 Oct 2020, at 21:38, Dan Smith < [ mailto:daniel.smith at oracle.com |
>> daniel.smith at oracle.com ] > wrote:
>>> ...
>> You're not wrong, but I'm not sure this is reason not to provide better typing
>> information. It certainly is the contract of the 'getPermittedSubclasses'
>> method not to pollute it with non-subclasses of T.
>> That said, Class<?>[] seems to be the precedent followed by other methods:
>> Class<? super T> getSuperclass()
>> vs.
>> Class<?>[] getInterfaces()
>> Constructor<T> getConstructor(Class<?>)
>> vs.
>> Constructor<?>[] getConstructors()
>> So I guess we should do the same with 'getPermittedSubclasses'.
> For reference, 8246278 "Refine API for sealing in java.lang.Class” [1], tracks
> this issue.
> An additional point for consideration, the return "container". Returning a
> Class<?>[] or maybe an immutable List<? extendsT>. The latter allows for
> sharper type information in the signature, the former does not.
yes,
but if getPermittedSubclasses() returns a List, we are back to the signature of getPermittedSubclasses() making it an outlier.
> -Chris.
Rémi
> [1] [ https://bugs.openjdk.java.net/browse/JDK-8246278 |
> https://bugs.openjdk.java.net/browse/JDK-8246278 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20201105/5da59a1e/attachment.htm>
More information about the amber-spec-experts
mailing list