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

forax at forax at
Mon Oct 26 11:04:40 UTC 2020

----- Mail original -----
> De: "John Rose" <john.r.rose at>
> À: "Remi Forax" <forax at>
> Cc: "Vicente Romero" <vicente.romero at>, "Brian Goetz" <brian.goetz at>, "Gavin Bierman"
> <gavin.bierman at>, "amber-spec-experts" <amber-spec-experts at>, "joe darcy"
> <joe.darcy at>
> Envoyé: Lundi 26 Octobre 2020 04:54:12
> Objet: Re: getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

> On Oct 24, 2020, at 3:32 PM, forax at wrote:
>> the 'get' was removed because the method was not returning Class objects, now
>> that permittedSubclasses behave like the other methods of java.lang.Class,
>> the name should be changed back to "get..." to reflect that.
> One reason (beyond good old consistency) to use the old
> name with the old type:  If we ever upgrade the return types
> from array to List<…>, we’ll want to use new method names.
> Using more than one naming convention for these methods
> reduces options for choosing a successor naming convention.

I believe it's better to introduce a new interface in between Collection and List, let say Array and refactor Object[]/int[]/... to implement Array.

> (Assuming we don’t have overload selection on return
> types, which I view as a very tempting idea but one that
> has yet to show a killer use case.)

It's OT but there are several reasons for using the return type in the overload selection are
- the inference is using the return type but not when overloading, many students find this weird
  (as they find weird to have contravariance of generics using wildcards but not contravariance of method parameter types when overriding)

- plain old ad-hoc polymorphism
  class Defaults {
    static int empty() { return 0; }
    static double empty() { return 0.0; }
    static <T> T empty() { return null; }

- be able to express covariant bridges in Java

I do not think there is a killer use case in this list anyway.


More information about the amber-spec-experts mailing list