[External] : Re: RFR: 8231436: Fix the applicability of a no- at Target annotation type

[Liam Miller-Cushon]

On Fri, Feb 5, 2021 at 4:52 PM Alex Buckley <alex.buckley at oracle.com> wrote:

> Is there a compatibility impact I am overlooking?
>

I don't think there's anything major, it's just the usual concern that this
is changing observable behaviour, and all observable behaviour of a system
will be depended on by somebody [1].

The least contrived example I can think of is that an annotation processor
might rely on TypeMirror#toString, and the string representation of types
will more often include type annotations, which could affect logic in the
processor or code that gets generated. (I think the javadoc bug I
encountered in JDK-8261203
<https://bugs.openjdk.java.net/browse/JDK-8261203> might be something like
that, where it's converting an annotated type to a string and not escaping
a string literal in the annotation element).

The additional attributes in the class file will also make them slightly
larger, which I think will increase metaspace usage ever so slightly, which
may be observable for some applications.

I agree that being able to add an explicitly @Target to annotations where
this is undesired is a relatively good and inexpensive workaround for the
cases that are affected.

If I was writing a CSR for this I'd probably estimate the compatibility
impact as 'low'--I think it's more than 'minimal', and it may deserve a
release note, but it's likely not prohibitively high. Does that sound right?

[1] https://www.hyrumslaw.com/  <https://www.hyrumslaw.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210205/46ebc845/attachment-0001.htm>