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

[Alex Buckley]

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
>