Why the annotation processing API ?

[joe darcy]

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

https://blogs.oracle.com/darcy/resource/JavaOne/J1_2014-Metadata.pdf

and about minute 30 of the youtube video:

     https://youtu.be/Ri5D9oCwI2Q?t=1810

Cheers,

-Joe


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.
> http://www.bracha.org/mirrors.pdf
>
> With the benefit of hindsight, these problems were avoided in the 
> language model portion of the annotation processing API, 
> javax.lang.model.
>
> Cheers,
>
> -Joe