RFR: 8343239: Javadoc marks non-preview type as preview if it's the subtype of a preview type [v2]

[Nizar Benalla]

On Mon, 25 Nov 2024 19:24:37 GMT, Hannes Wallnöfer <hannesw at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - dropping earlier idea/message as non-preview class should not have a preview message. As you do not need --enable-preview to use them.
>>    
>>    Removed some code and modified test accordingly
>>  - Merge remote-tracking branch 'upstream/master' into javadoc-preview-message
>>  - remove unused import
>>  - improve preview label message
>>  - fix preview bug
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2519:
> 
>> 2517:             target.add(previewDiv);
>> 2518:         } else if ((forWhat.getKind().isClass() || forWhat.getKind().isInterface())
>> 2519:                 && !utils.nonPreviewExtendsPreview(forWhat)) {
> 
> It appears you are excluding a type from getting a preview notice by checking a condition that is elsewhere used to decide it needs a preview notice. IMO the better solution would be to not give it a preview notice in the first place by not checking implemented interfaces for classes in `Utils.declaredUsingPreviewAPIs(Element)`. (An interface extending a preview interface is a different case again, although I don't think that should ever occur in the JDK.)
> 
> That leaves open the case where a preview interface introduces a default method (which is being fixed for javac in [JDK-8343540](https://bugs.openjdk.org/browse/JDK-8343540)), but I would consider that a separate issue.

I think I fixed it in [f8b3110](https://github.com/openjdk/jdk/pull/22126/commits/f8b3110c389d65c6cddbafbb28f554aeb93ebab1). The solution looks simpler without any of the added methods, thanks.

> (An interface extending a preview interface is a different case again, although I don't think that should ever occur in the JDK.)

Is this a typo? because I think this is exactly what the [PEM Encodings JEP](https://github.com/openjdk/jdk/pull/17543/files) does.


public non-sealed interface AsymmetricKey extends Key, DEREncodable {
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22126#discussion_r1858718859