RFR: 8231436: Fix the applicability of a no- at Target annotation type

Liam Miller-Cushon cushon at google.com
Sat Feb 6 00:18:53 UTC 2021


On Fri, Feb 5, 2021 at 6:45 AM Joel Borggren-Franck <
joel.p.borggren-franck at oracle.com> wrote:

> An alternative would be to adopt your original proposal, “all current and
> future declaration contexts”, and adding an ElementType corresponding to
> this default. This way the question “where are annotations applicable?”
> would be solved, the user can easily and with brevity opt in to all
> contexts by using something like “@Target({DECLARATIONS, TYPE_USE})" and
> the backward compatibility risk is lower. The downside is It would mean
> more work for us in implementing this.


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

> Encouraging the owner to specify @Target by offering an
> ElementType.DECLARATIONS constant that means "all [current and future]
> declaration contexts" is a good idea, balancing how ElementType.TYPE_USE
> means "all [current and future] type contexts".
>

I had a similar thought while updating the affected tests:
`@Target(DECLARATIONS)` would have been useful for a number of them.

I don't have a strong opinion either way about whether this change is worth
pursuing, or worth pursuing now. The simplicity of @Target-less annotations
applying to everything is appealing. I also think there's going to be some
noticeable compatibility impact, due to the number of annotations that will
start appearing in type contexts, and the number of tools that process
annotations that will need to become more robust in their handling of type
annotations.

If there's a tentative agreement that making @Target-less annotations apply
to everything together with introducing ElementType.DECLARATIONS is a
reasonable path forward, I can work on a proposal for that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210205/251fb622/attachment.htm>


More information about the compiler-dev mailing list