On Mon, 25 Nov 2024 19:24:37 GMT, Hannes Wallnöfer <[email protected]> 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