RFR: 8226216: parameter modifiers are not visible to javac plugins across compilation boundaries [v3]

[Jan Lahoda]

On Fri, 23 Apr 2021 12:41:13 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> javac fails to read modifiers from the MethodParameters attribute in class files, which prevents plugins from accessing those modifiers across compilation boundaries. Because `com.sun.tools.javac.jvm.ClassReader` doesn't read and store the access flags(modifiers) from MethodParameters attribute.
>> 
>> This patch fixes it and adds a corresponding test case. All the existing tests of javac passed locally.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Use meaningful class name and update copyright
>  - Merge branch 'master' into JDK-8226216
>  - Modify legal header. Fix typo.
>  - 8226216: parameter modifiers are not visible to javac plugins across compilation boundaries

test/langtools/tools/javac/classreader/ParameterModifiersAcrossCompilationBoundaries.java line 87:

> 85:                                         TypeElement typeElement = elements.getTypeElement("B");
> 86:                                         for (Element m : typeElement.getEnclosedElements()) {
> 87:                                             if (m instanceof ExecutableElement) {

Since this is a test, not so huge deal, but it might be better to do filtering using `ElementFilter.methodsIn` - it is easier to use than `Element.getKind()`, and safer than `instanceof` (which is not very much safe for `Element`s).

test/langtools/tools/javac/classreader/ParameterModifiersAcrossCompilationBoundaries.java line 148:

> 146:                 .options("--processor-module-path", "plugin", "-Xplugin:P",
> 147:                          "-parameters", "-classpath", "test")
> 148:                 .files("test/B.java")

Does the test really test the ClassReader behavior? It seems B is always originating in the source, and the test is looking at a parameter from the B file? Maybe the idea was `test/A.java` would be used here?

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

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