Annotations for language features

[Ted Neward]

> 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.
>
In hindsight, that's easy to say; I don't remember any sort of statement to
that effect when it was first shipped. I'm not making accusations or
espousing conspiracy theories, I just simply want to raise the idea that apt
was viewed by many--including me--as "the" Sun-blessed way to write
annotation processors.

Let me throw this in to the mix: what, for Java7, is similarly intended as
"the one we (Sun) plan to throw away"?

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 

> -----Original Message-----
> From: coin-dev-bounces at openjdk.java.net [mailto:coin-dev-
> bounces at openjdk.java.net] On Behalf Of Joseph D. Darcy
> Sent: Sunday, August 16, 2009 12:18 PM
> To: Adam Malter
> Cc: coin-dev at openjdk.java.net
> Subject: Re: Annotations for language features
> 
> 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