Request for feedback on annotation processing API changes made in JDK 9

Dawid Weiss dawid.weiss at gmail.com
Fri Apr 7 10:15:07 UTC 2017


Hello Joe,

I've tried this build on our simple preprocessor that extracts
metadata from existing types and builds some additional metadata
classes. Unfortunately we're getting an illegal access exception when
trying to access properties of the TypeElement object made available
to the processor (stack trace at [1]).

In short, the problem seems to be that we use Apache Velocity as a
template processor and pass those TypeElement instances for dynamic
introspection. When Velocity tries to access a property accessor
method (like getQualifiedName) it does so on the target class (not on
the interface) and consequently fails with cross-module access check.

I didn't dig deeper yet but I wonder how this kind of situation can be
worked around if the processor is used in the wild (where we have no
control and can't add --add-exports). Provide package-local wrapper
classes that call the target via the interface methods (TypeElement)?
Nothing else comes to my mind at the moment.

Dawid

[1]

    [javac] Caused by:
org.carrot2.util.preprocessor.shaded.apache.velocity.exception.VelocityException:
ASTIdentifier() : exception invoking method for identifier
'qualifiedName' in class com.sun.tools.javac.code.Symbol$ClassSymbol
...
[javac] Caused by: java.lang.IllegalAccessException: class
org.carrot2.util.preprocessor.shaded.apache.velocity.runtime.parser.node.PropertyExecutor
cannot access class com.sun.tools.javac.code.Symbol$ClassSymbol (in
module jdk.compiler) because module jdk.compiler does not export
com.sun.tools.javac.code to unnamed module @7cc586a8
    [javac]     at
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:370)
    [javac]     at
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589)
    [javac]     at java.base/java.lang.reflect.Method.invoke(Method.java:555)
    [javac]     at
org.carrot2.util.preprocessor.shaded.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:142)

On Thu, Apr 6, 2017 at 1:31 AM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> Hello annotation processing users and authors,
>
> As has been done previously during Java SE 7 and Java SE 8, the JSR 269
> annotation processing API is undergoing a maintenance review (MR) as part of
> Java SE 9.
>
> Most of the API changes are in support of adding modules to the platform,
> both as a language structure in javax.lang.model.* as well as another
> interaction points in javax.annotation.processing in the Filer and
> elsewhere. A small API change was also done to better support repeating
> annotations. A more detailed summary of the API changes as well as an issue
> list is included in the MR material:
>
> http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/summary-2017-03-27.html
> http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/issue-list-2017-03-27.txt
>
> A specdiff of the changes compared to Java SE 8 is also available:
>
> http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/specdiff-2017-04-05/
>
> The API changes are intended to be largely compatible with the sources of
> existing processors, their binary linkage, as well as their runtime
> behavior. However, it would be helpful to verify that your existing
> processors work as expected when run under JDK 9. JDK 9 early access
> binaries are available for download:
>
>     https://jdk9.java.net/download/
>
> The current build, b163, includes all planned changes to existing types. The
> next build, b164, scheduled to be available later this week will also
> include the type javax.annotation.processing.Generated. The new type
> javax.annotation.processing.Generated is intended to be a drop-in
> replacement for javax.annotation.Generated. (The type
> javax.annotation.Generated is in a module no longer visible by default.)
>
> Please report experiences running processors under JDK 9 and feedback on the
> API changes.
>
> Thanks,
>
> -Joe


More information about the compiler-dev mailing list