AnnotationProcessor

From APIDesign

Since JDK 1.6, its JavaC comes with standardized API for compile time processing of Annotations. Just by writing and registering a Processor in a JAR file of the API containing also the Annotations, one can effectively extend the compile time semantics of the Java language. By hooking into the compilation process of everyone using the JAR library, one can analyse all the Annotations usages, process them and generate additional files that can be then consumed during runtime.

NetBeans uses this style to convert nicely looking Annotations into a bit messy, yet powerful, layer XML file systems. This feature is available since version 6.7 released in 2009. Get more details about CompileTimeCaches!

Where is the limit? As LiveDB essay shows, there is none - download your database schema and include it as [[LiveDB|metadata of your compilation]!

There are very interesting aspects for BackwardCompatibility. By having own processor code running during compilation, one can keep own annotation unchanged across multiple releases, yet each of the new releases can generate something different during the compilation. As a result, one can deliver performance improvements, or even slightly shift mean of the API just by letting people compile their applications against new version of own libraries.

2009 - the Year of Annotations!?

As I noted recently, I see the year 2009 as the year of annotations. The NetBeans project is about to rely on them more heavily. Finally! We've been waiting for that for ages, but finally we can compile with JDK 1.6 JavaC and we can use compile time annotation processors. As a result we can replace our layer based registrations with annotations and benefit from compile type checking, code completion, from having the registrations in the same place as the code that is being registered, etc. Also we can offer our API users simple looking annotations and let associated annotation processors do more advanced and more effective processing. As a result the developers have simple API to deal with, while actual registration hidden behind can be as effective as possible, even at the cost of complexity, but without compromises to reliability (as the complexity is kept in the processing infrastructure, not exposed to API users).

The other project related to annotations that we are likely to incorporate during 2009 is our extended use of Annotations for Software Defect Detection. This is heavily based on the JSR 305, yet until it is stable we do not want to expose such unstable API to users of our stable APIs (more on that in Chapter 10, in section Beware of Using Other APIs). As such we are going to create our own annotations (still recognizable by FindBugs and co.). The hope is that our annotation will stay compatible even if the underlaying JSR 305 slightly changes. Please find our current patch and comment here or in the issue 137437.

Last project that deals with annotations is developed by our editor hints guru Jan Lahoda - its aim is to bring complex refactoring to masses! How? Why? We have observed that using @Deprecated annotation is good hint to help your API users recognize that some part of your API is obsolete and shall no longer be used, however that in no way helps users of your API with converting their code to new, non-deprecated style. We have a solution: Use Code Transformation Annotations! Dear [API] writers, let's adopt these annotations and use them in your API! They are completely standalone (read more), lightweight and we are ready to incorporate feedback of everyone interested in the project. Indeed, my plan is to bring these easy to use and flexible refactorings to NetBeans soon, hopefully for version 7.0.

So these are my three annotation related projects. I find them quite exciting and I cannot wait to see them being used. Annotations are here to simplify life of API users and developers. As soon as we have them, we will have full right to call the year 2009 the year of annotations!

Listen to our podcast or download it.