getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

[Remi Forax]

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