RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v2]

[Jonathan Gibbons]

On Wed, 21 Oct 2020 12:43:51 GMT, Hannes Wallnöfer <hannesw at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
>> 
>>  - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768
>>  - More fixing tests.
>>  - Fixing tests.
>>  - Using unique sections for preview warning sections, as suggested.
>>  - Merge branch 'master' into JDK-8250768
>>  - Reflecting review comments.
>>  - Fixing tests.
>>  - Various cleanup.
>>  - The Preview taglet is not needed anymore.
>>  - There is not jdk.internal package anymore
>>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 3164:
> 
>> 3162:     }
>> 3163: 
>> 3164:     public Set<ElementFlag> elementFlags(Element el) {
> 
> It seems like the sole use of this method and the `ElementFlag` enum below is to determine whether a preview warning note should be generated for an element. Is there something that speaks against simplifying it to reflect that purpose, e.g. change its name to `hasPreviewNote` or `hasPreviewContent` and change the return type to `boolean`?  Of course that's unless you foresee adding more `ElementFlag` values in the future.

There's a number of predicates on an element that the doclet might be interested in that could be cached/reified as "flags". Today, we have "preview" and "deprecated" that have similar handling; there have been discussions about handling native methods in a similar fashion.

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

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