Quantcast

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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

joe darcy
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dawid Weiss
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Gunnar Morling
In reply to this post by joe darcy
Hi Joe,

> The new type javax.annotation.processing.Generated is intended to be a drop-in replacement for javax.annotation.Generated

A @Generated annotation is useful for any kind of code generator,
whether implemented as an annotation processor or not. Having it in
javax.annotation.processing ties it to annotation processing, though.
Of course other non-AP generators may still use it, but it'd feel not
quite right.

When discussing the case of @Generated earlier this year on
jigsaw-dev, a proposal was to have java.lang.annotation.Generated, and
Mark expressed support for this [1]. I still think that'd be the
better place, or was there anything speaking against it?

Thanks,

--Gunnar

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-February/011365.html





2017-04-06 1:31 GMT+02:00 Joseph D. Darcy <[hidden email]>:

> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alex Buckley-3
In reply to this post by Dawid Weiss
On 4/7/2017 3:15 AM, Dawid Weiss wrote:
> 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.

Basically the same issue as "Using
java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes
InaccessibleObjectException" [1].

The fact that Velocity gets IllegalAccessException, not
InaccessibleObjectException, is probably because Velocity has found
'public' members (in this case, a nested type) and expects them to be
universally accessible.

> 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.

Please report a bug to Velocity. They've dealt with this kind of thing
over the years [2][3].

Alex

[1]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/010779.html
[2] https://issues.apache.org/jira/browse/VELOCITY-70
[3] https://issues.apache.org/jira/browse/VELOCITY-579
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alex Buckley-3
In reply to this post by joe darcy
On 4/5/2017 4:31 PM, Joseph D. Darcy wrote:
> http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/specdiff-2017-04-05/

- ModulePrefix in Processor::getSupportedAnnotationTypes would benefit
from using ModuleName (JLS9 6.5, 6.5.3) rather than TypeName.

- I was surprised that ModuleElement.Directive says "Represents a
***"module statement"*** within the declaration of this module." because
the whole point of adopting "directive" was to avoid reusing the term
"statement". Please consider borrowing terminology from JLS9 7.7 [1],
such as "The directives of a module declaration configure the module in
the Java Platform Module System."

- ModuleElement provides access to "information about the module, ***its
directives***, and its members."

- Semantically, ModuleElement::getSimpleName makes even less sense than
PackageElement::getSimpleName. At least for the latter, two
PackageElements having different simple names is a meta-level guarantee
that code in one package can't access package-access types in the other
package. But for the former, two ModuleElements having different simple
names tells you nothing about anything.

Alex

[1]
http://cr.openjdk.java.net/~mr/jigsaw/spec/java-se-9-jls-pr-diffs.pdf --
obviously not the Final Release, but 7.7 is a stable section number.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

joe darcy
In reply to this post by Gunnar Morling
Hi Gunnar,

On 4/7/2017 5:50 AM, Gunnar Morling wrote:
> Hi Joe,
>
>> The new type javax.annotation.processing.Generated is intended to be a drop-in replacement for javax.annotation.Generated
> A @Generated annotation is useful for any kind of code generator,
> whether implemented as an annotation processor or not. Having it in
> javax.annotation.processing ties it to annotation processing, though.
> Of course other non-AP generators may still use it, but it'd feel not
> quite right.

More specifically, the new Generated annotation type is tied to the
java.compiler module rather than the java.xml.ws.annotation module which
houses the old Generated.

> When discussing the case of @Generated earlier this year on
> jigsaw-dev, a proposal was to have java.lang.annotation.Generated, and
> Mark expressed support for this [1]. I still think that'd be the
> better place, or was there anything speaking against it?

After additional discussion, it seemed preferable to put the generated
annotation in a module related to code generation of some sort,
java.compiler, rather than the universally imported module java.base.

Thanks,

-Joe

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

mark.reinhold
2017/4/7 15:01:42 -0700, [hidden email]:
> On 4/7/2017 5:50 AM, Gunnar Morling wrote:
>> When discussing the case of @Generated earlier this year on
>> jigsaw-dev, a proposal was to have java.lang.annotation.Generated, and
>> Mark expressed support for this [1]. I still think that'd be the
>> better place, or was there anything speaking against it?
>
> After additional discussion, it seemed preferable to put the generated
> annotation in a module related to code generation of some sort,
> java.compiler, rather than the universally imported module java.base.

Yes -- just for the record, I agree with that.

- Mark
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dawid Weiss
In reply to this post by Alex Buckley-3
> Basically the same issue as "Using
> java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes
> InaccessibleObjectException" [1].

Thanks for the pointer, Alex. I followed up on that discussion. So my
intuition was basically correct (Method from the module-private class
instead of the exported API). Still, I fail to see how this can be
ever backward compatible and even fixable for many libraries that just
accept arbitrary Object instances and try to perform some reflective
operations on their public properties (or methods). Peter's advice
[1], while applicable, requires major changes to any scripting engine
out there to make it work.

Don't get me wrong, I understand it's a much better module isolation
sandbox and the concept is right. But speaking of backward
compatibility it's going to be a major one for existing scripting
engines. Consider Velocity -- those issues you pointed to are fairly
dated. In fact, last Velocity release was 7 years ago and somehow I
don't think tracking return types to get the right call methods is
going to be an easy fix...

Joe asked for feedback on the update, not the general module
compatibility, so this isn't really the same thread. Just wanted to
point out that this still leaves us in a situation where we have to
stick to Java8 or rewrite/fix the underlying scripting engine to make
it work with Java9 (command line switches cannot be considered if we
redistribute the annotation processor and expect it to work with
vanilla javac).

Dawid

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/010818.html
Loading...