AnnotationProcessor
From APIDesign
(New page: Since JDK 1.6, its JavaC comes with standardized API for compile time processing of Annotations. Just by writing and registering an [http://java.sun.com/javase/6/docs/api/j...) |
|||
| Line 1: | Line 1: | ||
Since [[JDK]] 1.6, its [[JavaC]] comes with standardized [[API]] for compile time processing of [[Annotations]]. Just by writing and registering an [http://java.sun.com/javase/6/docs/api/javax/annotation/processing/Processor.html AnnotationProcessor] in the [[JAR]] file 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. | Since [[JDK]] 1.6, its [[JavaC]] comes with standardized [[API]] for compile time processing of [[Annotations]]. Just by writing and registering an [http://java.sun.com/javase/6/docs/api/javax/annotation/processing/Processor.html AnnotationProcessor] in the [[JAR]] file 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, [[NetBeansLayers|layer XML file systems]]. This feature is available since version | + | [[NetBeans]] uses this style to convert nicely looking [[Annotations]] into a bit messy, yet powerful, [[NetBeansLayers|layer XML file systems]]. This feature is available since version 6.7 [[TheYearOfAnnotations2009|released in 2009]]. Get more details about [[CompileTimeCache]]s! |
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. | 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. | ||
Revision as of 04:44, 5 August 2009
Since JDK 1.6, its JavaC comes with standardized API for compile time processing of Annotations. Just by writing and registering an AnnotationProcessor in the JAR file 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!
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.
Follow
