Why the annotation processing API ?
joe.darcy at oracle.com
Mon Jun 6 16:15:34 UTC 2016
PS A concrete example of the design benefits of javax.lang.model over
core reflection is the relative ease of adding API support for type
annotations to javax.lang.model compared to core reflection.
This example is discussed in the 2014 JavaOne talk "Enhanced Metadata in
Java SE 8," starting around slide 22
and about minute 30 of the youtube video:
On 5/26/2016 9:07 AM, joe darcy wrote:
> On 5/25/2016 9:32 PM, Stéphane NICOLAS wrote:
>> Hi folks,
>> I know a simple mail like this generally has very minimal value. But
>> still, it's been around 2-3 years now that I work on Android, doing a
>> lot of work around reflection and annotation processing.
>> I don't like the annotation processing API. I still find every
>> concept hard to remember, and it is always taking time to get
>> immersed into it for a new project.
>> Thus, I don't understand, very humbly and very honestly, why this API
>> even exists. Why can't we simply use reflection-like APIs ? It would
>> not be that complex to expose an API that looks like reflection
>> (read-only of course, no new instance of classes, to method calls or
>> setting/getting field values, just the discovery part).
> The core reflection API has a number of serious design flaws, for a
> detailed discussion see
> Gilad Bracha and David Ungar. Mirrors: Design Principles for
> Meta-level Facilities of Object-Oriented Programming Languages. In
> Proc. of the ACM Conf. on Object-Oriented Programming, Systems,
> Languages and Applications, October 2004.
> With the benefit of hindsight, these problems were avoided in the
> language model portion of the annotation processing API,
More information about the compiler-dev