Evolution of annotation types - reducing set of supported targets

[Gunnar Morling]

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