RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v6]
Jan Lahoda
jlahoda at openjdk.java.net
Wed Nov 4 11:04:04 UTC 2020
On Mon, 2 Nov 2020 19:59:10 GMT, Jonathan Gibbons <jjg 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 46 commits:
>>
>> - Removing trailing whitespace.
>> - Merging master into JDK-8250768.
>> - Updating tests after records are a final feature.
>> - Fixing tests.
>> - Finalizing removal of record preview hooks.
>> - Merging master into JDK-8250768
>> - Reflecting review comments.
>> - Merge branch 'master' into JDK-8250768
>> - Removing unnecessary cast.
>> - Using a more correct way to get URLs.
>> - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Core.java line 28:
>
>> 26: import jdk.internal.javac.PreviewFeature.Feature;
>> 27:
>> 28: @PreviewFeature(feature=Feature.TEST)
>
> Yeah, I remember `Feature.TEST` from earlier. I guess it's OK for now, as a workaround for a testing a feature which is inherently, by design, a moving target across releases.
>
> These days, javadoc tests are trending towards generating small sample test programs, instead of having small static side-files dominated by a legal header. I wonder if there is a possibility of having a "generator class" in the `javadoc.tester` package that can generate sample code using one or more of the current set of preview features, as a way of reducing the need for the TEST feature.
I have intentionally added Feature.TEST to improve testability. Before, tests were using one of the constants (typically whatever was the first constant), but that seems somewhat problematic - what if (at some point, transiently) we have no preview features?
-------------
PR: https://git.openjdk.java.net/jdk/pull/703
More information about the compiler-dev
mailing list