On Tue, 8 Dec 2020 17:38:12 GMT, Chris Hegarty <che...@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