[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-compiler-dev
Subject: Re: JDK13 annotation processors not run when a supported annotation type specifies a module
From: Jonathan Gibbons <jonathan.gibbons () oracle ! com>
Date: 2020-01-16 23:57:08
Message-ID: 27d58a7a-79e7-34db-8152-fcba4d76fa81 () oracle ! com
[Download RAW message or body]
Suggestion inline:
-- Jon
On 01/16/2020 03:48 PM, Jeremy Kuhn wrote:
> Hi,
>
> I've just ran into this issue while testing annotation processors with
> JDK13. It happens when you specify a @SupportedAnnotationTypes
> annotation with annotation names prefixed with composite module names
> like the following:
>
> @SupportedAnnotationTypes({"com.example.moda/com.example.moda.annotation.SomeAnnotation"})
> public class ModuleAnnotationProcessor extends AbstractProcessor {
> ...
> }
>
> This is perfectly valid according to the documentation and was working
> just fine until JDK13
>
> "the name of the annotation type can be optionally preceded by a
> module name followed by a |"/"| character. For example, if a processor
> supports |"a.B"|, this can include multiple annotation types named
> > a.B| which reside in different modules. To only support |a.B| in the
> > Foo| module, instead use |"Foo/a.B"|. If a module name is included,
> only an annotation in that module is matched. In particular, if a
> module name is given in an environment where modules are not
> supported, such as an annotation processing environment configured for
> a source version
> <https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/annotation/processing/ProcessingEnvironment.html#getSourceVersion%28%29> \
> without modules, then the annotation types with a module name do /not/
> match." --
> https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/annotation/processing/Processor.html#getSupportedAnnotationTypes() \
> <https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/annotation/processing/Processor.html#getSupportedAnnotationTypes%28%29>
>
> I've track down the issue in JavacProcessingEnvironment.java to the
> following commit:
> https://hg.openjdk.java.net/jdk/jdk/diff/d84176dd57b0/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
>
> Some checks have been added to make sure supported annotation strings
> are valid and proper warning reported, unfortunately there's an error
> in the module's name check:
>
> private static Pattern importStringToPattern(boolean allowModules,
> String s, Processor p, Log log, boolean lint) {
> ....
> else {
> String moduleName = s.substring(0, slash);
> if (!SourceVersion.isIdentifier(moduleName)) {
It looks like this should use isName instead of isIdentifier.
> return warnAndNoMatches(s, p, log, lint);
> }
> ....
> }
>
> A module name is not a simple identifier like "moda",
> "com.example.moda" is also a valid module name as stated in the Java
> Language Specification (7.7). This results in always returning a no
> match pattern when such module name is used and the processor
> basically ignored.
>
> If we do not prefix the annotation with a module name, so there is a
> workaround but that doesn't match the API doc.
>
> Please let me know if I can help!
>
> Rgs
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Suggestion inline:<br>
</p>
-- Jon<br>
<br>
<br>
<div class="moz-cite-prefix">On 01/16/2020 03:48 PM, Jeremy Kuhn
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAD7F25yVSkQzx0O0bBjsn2FJgzkqPrn0+ufzcGeZuJ5iLYmUTA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
<div>I've just ran into this issue while testing annotation
processors with JDK13. It happens when you specify a
@SupportedAnnotationTypes annotation with annotation names
prefixed with composite module names like the following:<br>
</div>
<div><br>
</div>
<div>@SupportedAnnotationTypes({"com.example.moda/com.example.moda.annotation.SomeAnnotation"})<br>
public class ModuleAnnotationProcessor extends
AbstractProcessor {</div>
<div> ...<br>
</div>
<div>}</div>
<div><br>
</div>
<div>This is perfectly valid according to the documentation and
was working just fine until JDK13<br>
</div>
<div><br>
</div>
<div>"the name of the annotation type can be optionally preceded
by a module name followed by a <code> "/"</code> character.
For example, if a processor supports <code> "a.B"</code>,
this can include multiple annotation types named <code> a.B</code>
which reside in different modules. To only support <code> a.B</code>
in the <code>Foo</code> module, instead use <code>"Foo/a.B"</code>.
If a module name is included, only an annotation in that
module is matched. In particular, if a module name is given in
an environment where modules are not supported, such as an
annotation processing environment configured for a <a
href="https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/annotation/processing/ProcessingEnvironment.html#getSourceVersion%28%29"
moz-do-not-send="true">source version</a> without modules,
then the annotation types with a module name do <em>not</em>
match." -- <a
href="https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/annotation/processing/Processor.html#getSupportedAnnotationTypes%28%29"
moz-do-not-send="true">https://docs.oracle.com/en/java/javase/11/docs/api/java.compi \
ler/javax/annotation/processing/Processor.html#getSupportedAnnotationTypes()</a></div>
<div><br>
</div>
<div>I've track down the issue in
JavacProcessingEnvironment.java to the following commit: <a
href="https://hg.openjdk.java.net/jdk/jdk/diff/d84176dd57b0/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java"
moz-do-not-send="true">https://hg.openjdk.java.net/jdk/jdk/diff/d84176dd57b0/src/jdk \
.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java</a></div>
<div><br>
</div>
<div>Some checks have been added to make sure supported
annotation strings are valid and proper warning reported,
unfortunately there's an error in the module's name check:<br>
</div>
<div><br>
</div>
<div>private static Pattern importStringToPattern(boolean
allowModules, String s, Processor p, Log log, boolean lint) {</div>
<div> ....<br>
</div>
<div> else {<br>
String moduleName = s.substring(0, slash);<br>
if (!SourceVersion.isIdentifier(moduleName)) {<br>
</div>
</div>
</blockquote>
<br>
It looks like this should use isName instead of isIdentifier.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAD7F25yVSkQzx0O0bBjsn2FJgzkqPrn0+ufzcGeZuJ5iLYmUTA@mail.gmail.com">
<div dir="ltr">
<div> return warnAndNoMatches(s, p, log, lint);<br>
}</div>
<div> ....<br>
</div>
<div>}</div>
<div><br>
</div>
<div>A module name is not a simple identifier like "moda",
"com.example.moda" is also a valid module name as stated in
the Java Language Specification (7.7). This results in always
returning a no match pattern when such module name is used and
the processor basically ignored.</div>
<div><br>
</div>
<div>If we do not prefix the annotation with a module name, so
there is a workaround but that doesn't match the API doc.</div>
<div><br>
</div>
<div>Please let me know if I can help!</div>
<div><br>
</div>
<div>Rgs<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic