RFR: 8261625: Add `Elements.isAutomaticModule(ModuleElement)`

Vicente Romero vromero at openjdk.java.net
Thu Apr 8 02:03:07 UTC 2021

On Wed, 7 Apr 2021 18:49:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Addition of a small convenience method, with a default implementation, to Elements.
> Most of the change is testing infrastructure. The negative cases, such as named modules, are tested in the style of other annotation processing tests for Elements utilities.
> An automatic module comes from a jar file, so an API reading from a jar file is needed. To avoid piping in the awkward plumbing needed to do that directly in the annotation processing tests, I updated an existing automatic modules test which uses the tool box facility. My additions to the tool box might not be the done in the most idiomatic style for that API; happy to have guidance on how to proceed better there.
> Assuming this general approach is agreed to, I'll update the imports on AutomaticModules.java to condense the text of the annotation processor source.

Changes requested by vromero (Reviewer).

test/langtools/tools/lib/toolbox/JavacTask.java line 341:

> 339:      * @return the result of calling {@code run}
> 340:      */
> 341:     public Result run(Expect expect, Processor... procs) {

I would prefer to add a new method to this class, something in the lines of:
public JavacTask processors(Processor... procs) {
    this.procs = List.of(procs);
    return this;

which I think is more in the spirit of the existing API, then you won't need to add the two new versions of the `run` method


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

More information about the compiler-dev mailing list