RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3]

Mandy Chung mchung at openjdk.java.net
Tue Dec 8 18:06:15 UTC 2020

On Tue, 8 Dec 2020 17:38:12 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 4399:
>>> 4397:      * that is {@link #isSealed()} returns {@code false}, then this method returns {@code null}.
>>> 4398:      * Conversely, if {@link #isSealed()} returns {@code true}, then this method
>>> 4399:      * returns a non-null value.
>> @ChrisHegarty minor but I prefer a simpler alternative to address your concern is to add a link to the reference to "sealed class or interface" to `Class::isSealed` as follows:
>> implement this class or interface if it is {@linkplain #isSealed() sealed}.
>> The order of such elements is unspecified. If this {@code Class} object
>> represents a primitive type,  is unspecified. The array is empty if this
>> {@linkplain #isSealed() sealed} class or interface has no permitted subclass. 
>> If this {@code Class} object represents a primitive type, {@code void}, an array type,
>> or a class or interface that is not sealed, then this method returns {@code null}.
> There is certainly a little redundancy in the additional spec wording
> that I proposed. In my view it is worth it, as it allows the reader to
> more easily grok the null versus empty array for non-sealed classes,
> without having to navigate between the pair of methods.

I see this new pattern introduced in `getRecordComponents`.  You may consider if this pattern should consistently applied in other `Class` APIs such as `getEnumConstants`.


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

More information about the compiler-dev mailing list