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

Sat May 15 23:01:32 UTC 2021

I concur with Alex:  an annotation defined without a @Target annotation
should be applicable to all contexts.
Some wording goofs have caused confusion about the intent and the effect,
but we have an opportunity now to clarify that.

Mike

On Wed, Feb 3, 2021 at 10:39 AM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Let me focus first on the design question of what a no- at Target
> annotation type "means". There's no particular reason why it _shouldn't_
> mean "all contexts". Mike gave good reasons why it should mean that. For
> the corner case of an annotation appearing in one of the ambiguous
> locations in source code, the annotation will appear in the class
> file/via reflection exactly as if someone had taken the perfectly
> legitimate course of spelling out @Target({METHOD, TYPE_USE}) -- the
> no- at Target case is not a secret door to behavior that's otherwise
> impossible or undesirable.
>
> (We could have said "all contexts" for a no- at Target annotation type but
> then added a rule in 9.7.4 to special-case a no- at Target annotation that
> appears in an ambiguous location, e.g., to compile the annotation as if
> it was applicable only in declaration contexts. More compatibility with
> SE 8, but more complexity, and I don't think anyone really wants that.)
>
> Turning to the compatibility concern: yes, JDK-8231435 shouldn't have
> claimed behavioral compatibility. It was my error to not recognize what
> Mike was saying in "It is a behavior change from the current
> specification, but a small one that affects poorly-written programs that
> have no @Target meta-annotation." Still, at the end of the day, it's no
> more than a small behavioral incompatibility for annotation processors
> (they may see more type annotations than they did before), and one which
> was within the power of the annotation type's owner to induce anyway
> (annotation processors that look for type annotations can reasonably be
> expected to ignore type annotations in places they don't care about).
>
> I have cc'd Mike in case he wants to add anything further, but the
> design intent of "all contexts" still looks reasonable to me.
>
> Alex
>
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210515/fde049d8/attachment.htm>