On Mon, 2 Nov 2020 19:59:10 GMT, Jonathan Gibbons <j...@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

Reply via email to