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