Evolution of annotation types - reducing set of supported targets

Gunnar Morling gunnar at hibernate.org
Thu Jun 29 13:29:26 UTC 2017

Joe, Alex, thanks a lot for the clarification!

2017-06-28 23:17 GMT+02:00 Joseph D. Darcy <joe.darcy at oracle.com>:
> 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:
>     https://wiki.openjdk.java.net/display/csr/Kinds+of+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.
> -Joe

More information about the compiler-dev mailing list