On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero <vrom...@openjdk.org> wrote:
> Please review the code for the second iteration of sealed classes. In this > iteration we are: > > - Enhancing narrowing reference conversion to allow for stricter checking of > cast conversions with respect to sealed type hierarchies > - Also local classes are not considered when determining implicitly declared > permitted direct subclasses of a sealed class or sealed interface > - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still > in the same method, the return type has been changed to Class<?>[] instead of > the previous ClassDesc[] > - adding code to make sure that annotations can't be sealed > - improving some tests > > TIA > > Related specs: > [Sealed Classes > JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html) > [Sealed Classes > JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html) > [Additional: Contextual > Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html) src/java.base/share/classes/java/lang/Class.java line 4381: > 4379: */ > 4380: > @jdk.internal.PreviewFeature(feature=jdk.internal.PreviewFeature.Feature.SEALED_CLASSES, > essentialAPI=false) > 4381: public Class<?>[] getPermittedSubclasses() { What happens if a permitted subclass is not found? I see that `getPermittedSubclasses0` ignores the entry if the class is not found. Should that be specified? Have you considered whether security package access is needed (now that this method returns `Class` objects the caller may not have access to)? This needs to be discussed with the security team. If someone gets a hold of a sealed class (e.g. `obj.getClass()`), this method could leak other `Class` objects. ------------- PR: https://git.openjdk.java.net/jdk/pull/1227
