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

[Joe Darcy]

Hello,

To me, it seems that intending an annotation to be used on declarations 
or on types is a basic design decision of the annotation type. I think 
it can be reasonable to interpret lack of @Target to mean "usable in any 
declaration context," but ill-advised to silently reinterpret absence of 
a @Target to indicate types and declarations.

Cheers,

-Joe

On 2/3/2021 5:29 AM, Joel Borggren-Franck wrote:
> Hi Alex,
>
> Looking at  the class file, and therefore reflection, there is a difference between “all declaration contexts” and “all contexts, declaration + type”. For the 5 ambiguous locations we would have to produce type annotation attributes if there is an annotation present whose declaration lack @Target. While this may or may not be desirable, and I’m leaning towards not, it is surely significant as it would change the semantics of reflective annotation processors in use.
>
> cheers
> /Joel
>
>> On 2 Feb 2021, at 19:50, Alex Buckley <alex.buckley at oracle.com> wrote:
>>
>> I initially proposed "all declaration contexts" as the smallest possible streamlining of the SE 7-oriented rule defined in SE 8. It would have ensured that legacy annotation types without @Target were locked out of the new world of type uses enabled in SE 8 by JSR 308. As it turned out, my conservative approach was unnecessary because Mike was fine with admitting those legacy annotation types for type uses via the "all contexts" rule. In the real world, "all declaration contexts" versus "all declaration contexts + all type contexts" is a distinction without a difference (that is, an insignificant distinction) -- we're best off adopting the latter rule, phrased simply as "all contexts".
>>
>> Alex
>>
>> On 2/2/2021 3:44 AM, Guoxiong Li wrote:
>>> On Tue, 2 Feb 2021 09:28:59 GMT, Joel Borggrén-Franck <jfranck at openjdk.org> wrote:
>>>>> Thanks for the comments,
>>>>>
>>>>> @jbf I'll add a more focused test. For the bug, the original discussion in https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html is specifically about annotations without an explicit `@Target` applying to `MODULE`, I don't think there's anything that needs to be done for [JDK-8231436](https://bugs.openjdk.java.net/browse/JDK-8231436) besides supporting `MODULE`, would you still prefer a separate bug?
>>>>>
>>>>> @jddarcy note that there was already a spec change related to this in [JDK-8231435](https://bugs.openjdk.java.net/browse/JDK-8231435) and the spec bug mentions "this expansion is source, binary, and behaviorally compatible", should I still file a CSR?
>>>>  From this follow up here: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html my interpretation is that this bug was intended to widen it to all contexts, including type use. This has been changed in JLS but not in the normative javadoc and also not in the compiler. I believe we should keep declarations only, and back out the change to JLS.
>>> Maybe we should collect the concrete information about this problem. Here are some materials that I know.
>>> Order by time:
>>> - 2019.08 **Werner Dietl** launched the discussion. [1]
>>> - 2019.09 After the discussion between **Alex Buckley** and **Michael Ernst**, an initiative result came out.[2]
>>> - 2019.09 Two JBS issues were filed. [3][4]
>>> - 2019.12 **Alex Buckley** fixed the JLS(fix version: 14). But the compiler code and javadoc were not fixed. [5][6]
>>> - 2020.10 **Christian Stein** created another issue about it. [7]
>>> - 2020.10 **Guoxiong Li**(me) submitted a PR about it in Github. [8]
>>> - 2020.10 **Joel Borggrén-Franck** restarted the discussion about the specification. [9]
>>> - 2020.12 Because the JDK16 was nearly at RDP1, we decided to only fix JDK-8254023. And other work left to JDk17.  [7][10][11]
>>> - 2020.12 The issue JDK-8254023 was fixed at JDK16. [7][8][12]
>>> - **Now, we need to discuss the problem(unify the specification, implement and javadoc) that JDK16 has left.**[11]
>>> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html
>>> [2] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8231435
>>> [4] https://bugs.openjdk.java.net/browse/JDK-8231436
>>> [5] https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6.4.1
>>> [6] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/annotation/Target.html
>>> [7] https://bugs.openjdk.java.net/browse/JDK-8254023
>>> [8] https://github.com/openjdk/jdk/pull/622
>>> [9] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015197.html
>>> [10] http://openjdk.java.net/projects/jdk/16/
>>> [11] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015503.html
>>> [12] https://github.com/openjdk/jdk16/pull/34
>>> -------------
>>> PR: https://git.openjdk.java.net/jdk/pull/2303