Evolution of annotation types - reducing set of supported targets

Joseph D. Darcy joe.darcy at oracle.com
Wed Jun 28 21:17:52 UTC 2017

On 6/28/2017 11:19 AM, Alex Buckley wrote:
> On 6/28/2017 1:23 AM, Gunnar Morling wrote:
>> I'm trying to figure whether removing an element type from an
>> annotation's set of supported targets is considered to break binary
>> compatibility or not.
> Binary compatibility concerns the JVM's ability to continue to link 
> the changed class. Since linking does not care about annotations, any 
> change to an annotation's type is binary compatible. Your issue is 
> nothing to do with binary compatibility, but rather with the specified 
> behavior of the Core Reflection API when an annotation's presence is 
> out of sync with the annotation's type. I believe the Core Reflection 
> API is designed to be extremely forgiving in these circumstances.

In the terminology used by the CSR (compatibility and specification 
review) process, that kind of compatiblity under discussion is called 
behavioral compatiblty rather than binary compatibility:


By design, annotations are checked more loosely than other aspects of 
the platform. For example, malformed annotation information in class 
files will only trigger exceptions to be thrown if there is an attempt 
to read the annotations; the annotation data is just ignored otherwise.

In that spirit, the core reflection implementation generally does not do 
heroic efforts to check for compile-time vs runtime inconsistencies in 
annotation usage, such as changing the set of valid targets.


More information about the compiler-dev mailing list