Annotations for language features
Joseph D. Darcy
Joe.Darcy at Sun.COM
Sun Aug 16 12:17:49 PDT 2009
Adam Malter wrote:
> On Sun, Aug 16, 2009 at 2:23 PM, Artur Biesiadowski<abies at adres.pl> wrote:
>> Reinier Zwitserloot wrote:
> I think anybody who's worked with 'code generating' annotation
> processors could enumerate a number of good reasons to stay away.
> They have been universally fragile, difficult to test, difficult to
> code and difficult to debug. Additionally, they place a serious
> complexity and runtime strain on development tools. The 'code' must be
> generated realtime in order to preserve 'as your type' error hints
> (aka, insure an accurate AST model with references back to true source
> code). Additionally, they introduce dependency graphs that are not
> clearly resolved even by the current generation of annotation parsers
> (See Joe Darcy's attempt to build a *third* Apt API in as many
> versions of Java and then lookup the concept of generation rounds in
> the Eclipse apt development documentation)
I don't know what attempt at a third API you are referring to.
The apt tool and API was always planned to be "the one we throw away" in
the "The Mythical Man-Month" sense, which is why it has been deprecated
in JDK 7 and is planned for removal in a future JDK release.
The JSR 269 API (javax.annotation.processing, javax.lang.model.*)
improves significantly on apt and JSR 269 was informed by experiences
BEA engineers gained from implementing apt in an IDE.
The JSR 269 API is being tweaked a bit in JDK 7 and can be expected to
change further to support new language features. Supporting language
evolution smoothly was a key technical goal of JSR 269 specifically to
*avoid* introducing yet another API in JDK 7.
More information about the coin-dev