On Tue, 1 Dec 2020 23:19:41 GMT, Mandy Chung <mch...@openjdk.org> wrote:
>> 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. Yes, would be a surprise if getPermittedSubclasses returned Class objects for classes that are not subclasses. I think it should be okay to separate that out to a separate issue so that it can be further re-examined after JEP 397 goes in. ------------- PR: https://git.openjdk.java.net/jdk/pull/1483
