New JSR 269: Pluggable Annotation Processing API

Discussions

News: New JSR 269: Pluggable Annotation Processing API

  1. New JSR 269: Pluggable Annotation Processing API (18 messages)

    J2SE 1.5 added a new Java language mechanism "annotations" that allows annotation types to be used to annotate classes, fields, and methods. These annotations are typically processed either by build-time tools or by run-time libraries to achieve new semantic effects. In order to support annotation processing at build-time, this JSR will define APIs to allow annotation processors to be created using a standard pluggable API. This will simplify the task of creating annotation processors and will also allow automation of the discovery of appropriate annotation processors for a given source file.

    The specification will include at least two sections, a section of API modeling the Java programming language and a distinct section for declaring annotation processors and controlling how they are run. Since annotations are placed on program elements, an annotation processing framework needs to reflect program structure. Annotation processors will be able to specify what annotations they process and multiple processors will be able to run cooperatively.

    The processors and program structure api can be accessed at build-time; i.e. this functionality supplements core reflection support for reading annotations.

    Read more at the JCP: JSR 269: Pluggable Annotation Processing API

    Threaded Messages (18)

  2. Ehhhm, okay, well, ahhhh...[ Go to top ]

    So there is no standarized support for processing annotations outside a running JVM. And JSR269 wants to add support for accessing them at build time.

    I'm a bit uncertain on how to see this. Are these compiler extentions? Most tools are written in Java, so there always is a JVM to access the annotations from. I mean:
    - compile sources to a tmp location
    - start the tool (tmp location in classpath) and access the annotations

    So I cannot see it any way than compiler extentions reacting when the source code is being compiled. Would this mean that I can add methods and other elements during compilation? (I want my "@setter @getter private int size;")
  3. Xdoclet anyone?[ Go to top ]

    This sounds a lot more like a possible way to build Xdoclet-like processing API IMHO. I like it.
  4. Ehhhm, okay, well, ahhhh...[ Go to top ]

    Yes. You should be able to do your (and mine) favorite @getter @setter private int size. Problem is with tools. Question is if you will be able after such declaration use in e.g. Eclipse getSize() method with autocompletition. I hope this is a first step.
  5. reflection[ Go to top ]

    As long as it's foreseen as a reflective API and Eclipse's (and other IDEs) completion works with reflection, I guess it'll be possible and very convenient (but troubling for newbies... a completion for a method you can't directly see.... ;) ).
  6. Ehhhm, okay, well, ahhhh...[ Go to top ]

    Question is if you will be able after such declaration use in e.g. Eclipse getSize() method with autocompletition.

    My worries exactly. However, from what I have seen in Eclipse one needs to save a java file before autocompletion can be used on it from another file. Hence the autocompletion probably examines the resulting class file and as such should be able to find generated setters and getters.
  7. The JSR proposal looks exactly as the APT, which is already part of JDK 5.

    http://java.sun.com/j2se/1.5.0/docs/guide/apt/
    From APT docs: apt is a command-line utility for annotation processing. It includes a set of reflective APIs and supporting infrastructure to process program annotations (JSR 175).

    And on the JSR 269 description:
    2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
    The intent is to supersede the com.sun.mirror.* APIs and the apt tool shipped as part of Sun's JDK 5.


    So what ?
    APT is already deprecated ? What does this JSR 269 brings ? Tighter integration with "javac" (instead of "apt") ? A way to change the class file of the annotated class beeing proceesed ?

    Alex
  8. limitations?[ Go to top ]

    You can also see this in the JSR 269 :

    3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

    This JSR is targeting the same general functionality as the apt tool, http://java.sun.com/j2se/1.5.0/docs/guide/apt/index.html. It is expected the API included in this JSR will resemble but not necessarily be compatible with the existing apt API.

    We expect some coordination with JSR199 to avoid designing overlapping functionality.

    3.2 Explanation of how these items might be used as a starting point for the work.

    Users of apt have identified several limitations to the API; this feedback should be considered by the expert group.
  9. ditto[ Go to top ]

    So what ?APT is already deprecated ? What does this JSR 269 brings ? Tighter integration with "javac" (instead of "apt") ? A way to change the class file of the annotated class beeing proceesed ?Alex

    Ditto. I think there are a few projects like JDO, AspectJ, JBoss AOP that might like to use annotations to post-process bytecode.
  10. ditto[ Go to top ]

    Hi Bill

    That s exactly the kind of limitation I see in APT. But is that worth a whole new JSR just after APT shipped. Can't we simply make APT evolve to support that ?

    F.e. Apache Beehive is already making extensive use of it and I suspect other projects have started so as well.

    Could someone from Sun or from one of the expert groups (175 or that one) comment on that ?

    Alex
  11. As I see it, APT is not a standard since it was not the product of a JSR but is "just" part of the Sun JDK 5.0. This can also be seen by the fact that to write annotation processors for APT you work with classes below the com.sun.mirror hierarchy.

    JSR 269 seems to be an attempt to standardize (via the JCP) something like APT, how to write annotation processors for it and how they are registered with a tool like APT.

    Also, APT operates on Java *source* and hence the annotation processors needs an object-representation of the source-code structure they work on. This representation looks similar to what we know from reflection but is really on the source level. This will be standardised by JSR 269, too.

    Finally, annotation processors may generate arbitrary "source" but, to my understanding, may not alter the source they process.

    An annotation processor (as understood by APT) thus seems to me clearly distinct from a bytecode post-processor such as needed by JDO implementations. Don't know if JSR 269 will allow these aspects to be merged somehow...

      my two cents,
      gerald

    --
    http://www.gerald-loeffler.net
  12. ditto[ Go to top ]

    Hi BillThat s exactly the kind of limitation I see in APT. But is that worth a whole new JSR just after APT shipped. Can't we simply make APT evolve to support that ?F.e. Apache Beehive is already making extensive use of it and I suspect other projects have started so as well.Could someone from Sun or from one of the expert groups (175 or that one) comment on that ?Alex

    The benefit of the JSR for current APT users would be to have a set of APIs for authoring an annotation processor that are standard (part of the javax.* or java.* package space) with the associated guarantees for back compat, downstream support, etc. Today, all of the APT APIs live in the com.sun.* space with no such guarantees.

    Ditto for tool vendors... if they want to expose APT-compatible functionality in compilers or or elsewhere, they have to expose it as com.sun.* interfaces.

    The benefit to the overall community would be that it presents an opportunity to form an expert group and participate in a discussion about annotation processing functionality, possibly addressing some of the limitations of the current APT implementation. The end result could well be something derivative of the current APT implementation, not a standardization of the existing APIs.

    I personally see this as a good thing for JSR-175 in general... just defining class file formats and reflection access APIs leaves a big gap for tools/projects that want to process annotations, particularly if they aren't retained in the class files.

    -- Kyle Marvin
       Apache Beehive project
  13. not so ditto[ Go to top ]

    IMHO, frameworks should stay away from byte-code manipulation during compiletime if possible. Annotations (as I stated in my article at ONJava) are 'read' from objects. When 2 or 3 different frameworks now have the capabilities to 'write' to objects (at compilation)-- who knows what the end product might end up being?

    .NET also has an attribute system which is 'readable' from objects just as they are in J2SE 5. Frameworks should allow developers to declare annotations on their objects that are 'read' when the object is passed into the framework's context. This preserves the generic capabilities of an object and would provide the flexibility to work in all framework contexts.

    So I'm not saying that the goals of this JSR are bad, just that frameworks should only try to pursue compile-time annotation processing as a last resort.
  14. not so ditto[ Go to top ]

    IMHO, frameworks should stay away from byte-code manipulation during compiletime if possible. Annotations (as I stated in my article at ONJava) are 'read' from objects. When 2 or 3 different frameworks now have the capabilities to 'write' to objects (at compilation)-- who knows what the end product might end up being?.NET also has an attribute system which is 'readable' from objects just as they are in J2SE 5. Frameworks should allow developers to declare annotations on their objects that are 'read' when the object is passed into the framework's context. This preserves the generic capabilities of an object and would provide the flexibility to work in all framework contexts.So I'm not saying that the goals of this JSR are bad, just that frameworks should only try to pursue compile-time annotation processing as a last resort.
  15. not so ditto[ Go to top ]

    So I'm not saying that the goals of this JSR are bad, just that frameworks should only try to pursue compile-time annotation processing as a last resort.

    It's worth noting that compile-time annotation processing does not necessarily imply bytecode manipulation. In some contexts, you may want to generate other artifacts (supporting classes, deployment descriptors, ...) that are needed at runtime, but might also need to exist prior to runtime.

    A concrete example can be found in Apache Beehive Controls. This offers (among other things) an enhanced authoring model for JavaBeans, where user can declare things like properties or events as part of an interface that defines the bean public contract and be spared the mundane work of manually writting setters/getters, listener mgmt, etc. for the bean class itself.

    In the case of controls, annotation processing generates the JavaBean class that wraps the (un-byte-code-modified) class the user has authored, BeanInfo classes, supporting JAR manifest entries, etc. Since other sources might want to reference the bean type, tools might want to use BeanInfo, etc, it clearly has to be generated at compile-time, not run-time.

    -- Kyle

    [apologies for the premature post above]
  16. I had written an article on using runtime reflection of annotations for handling framework concerns. It uses the example of building validation onto your setters and discusses the future of framework configuration. Also, read some of the comments as one developer brought up some good questions on the approach I describe:

    "Validating Objects Through Metadata"
  17. Ahh, Annotation Based Programming...[ Go to top ]

    Frankly, I find it somewhat shocking that Java evolves more and more into some sort of C++/C# clone. "Annotation processing at compile time" essentially means overblown compiler directives. Yuck. Also very strange that features get added to the language for a single use case (like variable args for using printf (bizarre), templates for the sole purpose to get a little more convinient collection etc. etc.).

    Annotations blow it for me though, because not only because they denote a questionable principle (but then what doesn't) but because of the totally awkward syntax. Hey, great we can go ahead and embrace the Perl community - the original providers of unreadable code (TM)! Now really!
  18. Ahh, Annotation Based Programming...[ Go to top ]

    The very wide usage of xdoclet shows that there is a true need for meta-data on Java artifacts. You can argue against it on aesthetic or theoretical grounds (e.g. introducing dependencies on your database schema into the Java-code of your persistent business objects through annotations is one questionable but very common and, in fact, quite effective use of meta-data) but the need is still very real.

      cheers,
      gerald

    --
    http://www.gerald-loeffler.net
  19. Java Evolving[ Go to top ]

    So what if Java evolves? I think it is good that Java gains more and powerful features, even if they are borrowed from C++ or C#, as long as it doesn't repeat the mistakes those languages make in designing them. Annotation Processing allows us to (potentially) write the statements that matter and let the boilerplate be automatically generated, allowing us to factor out the parts that can't be generalized with APIs. All these features increase productivity, and the less code you write, the fewer mistakes you make. What matters is that, the new features do not complicate the work of those who don't need to use those features. I can’t to see how having annotation processing complicate code. Sure, it is possible to write obfuscated annotation processors and tools. But the same can be said about any other kind of programming. Just like someone can write an obfuscated library.