On Tue, 1 Dec 2020 16:49:03 GMT, Jan Lahoda <[email protected]> wrote:
>> So it could also return a class listed in `PermittedSubclasses` attribute
>> but not a subclass of this sealed class, right?
>>
>> The specification of `Class::getPermittedSubclasses` says:
>>
>>> Returns an array containing {@code Class} objects representing the direct
>>> subclasses or direct implementation classes permitted to extend or direct
>>> subinterfaces or subclasses permitted to extend or implement this class or
>>> interface if it is sealed.
>>
>> I expect that `Class::getPermittedSubclasses` should do more work and return
>> only the subclasses or subinterfaces permitted at runtime.
>
> I was investigating a little today. One thing to note is that there is a
> difference between the JLS and JVMS[1] restrictions - the JVMS restrictions
> only require the classes to be in the same module, but they can be in any
> package (even for an unnamed module).
>
> Moreover, a lot of the constraints are checked automatically: e.g. consider
> class api.Api in module "a", which permits impl.Impl in module "b", subtyping
> Api. Loading of impl.Impl on behalf of getPermittedSubclasses() will fail
> (because the two classes are in different modules). So impl.Impl will not be
> included.
>
> So far, it seems the only constraint that I think is not satisfied by this
> implicit loading is that the permitted subclass is really a direct subtype of
> the current class.
>
> My proposal is to enhance the Java method with the direct subtype check (with
> a possible future cleanup task to move the check to native, as is done for
> getNestMembers()).
>
> [1]
> http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html#jvms-5.3.5
@lahodaj It is okay with me if `getPermittedSubclasses` returns the permitted
subtypes matching the runtime view (that matches the current specification to
me) and revisit this API as a follow up.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1483
