On Tue, 8 Dec 2020 17:18:20 GMT, Mandy Chung <mch...@openjdk.org> wrote:
>> Harold Seigel has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8256867: Classes with empty PermittedSubclasses attribute cannot be
>> extended
>
> 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1675
