Annotations for language features

[Joseph D. Darcy]

Adam Malter wrote:
> On Sun, Aug 16, 2009 at 2:23 PM, Artur Biesiadowski<abies at adres.pl> wrote:
>   
>> Reinier Zwitserloot wrote:
>>     
>>

[snip]
>
> 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.

-Joe