RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

[Mandy Chung]

On Mon, 16 Nov 2020 13:49:26 GMT, Alan Bateman <alanb at 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/Package.java line 227:
> 
>> 225:      * This method reports on a distinct concept of sealing from
>> 226:      * {@link Class#isSealed() Class::isSealed}.
>> 227:      *
> 
> This API note will be very confusing to readers. I think the javadoc will need to be fleshed out and probably will need to link to a section the Package class description that defines the legacy concept of sealing.

I agree.  This @apiNote needs more clarification to help the readers to understand the context here.    One thing we could do in the Package class description to add a "Package Sealing" section that can also explain that it has no relationship to "sealed classes".

-------------

PR: https://git.openjdk.java.net/jdk/pull/1227