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:
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