[type-annos-observers] Fw: Constraining type annotations to occur just before type

[Srikanth S Adayapalam]

Follow up comments from Markus Keller, IBM (Eclipse JDT/UI lead)

Srikanth

----- Forwarded by Srikanth S Adayapalam/India/IBM on 04/12/2013 03:57 PM
-----

From:	Markus Keller/Zurich/IBM at IBMCH
To:	Srikanth S Adayapalam/India/IBM at IBMIN@IBMDE,
Date:	04/10/2013 09:31 PM
Subject:	Re: Fw: Constraining type annotations to occur just before type


> I don't understand what this "client code" is. The only place where
> "semantics" is a valid concern is if code starts to use SE 8 API methods
> to read type annotations, since they will appear on the ground type
> (String) which may not have been the intended location (String[]) circa
> SE 7.

With "client code", I mean Java 7 code that uses an annotation and some
compiler add-on that processes the annotation. E.g. the cited
    @NonNull final String[] s3;
or even
    @NonNull final java.lang.String s4; // legal ONLY for declaration
annot.
    final java.lang. at NonNull String s5; // legal ONLY for type-use
annotations

The @NonNull annotation has some semantics that are defined by the
annotation type and the compiler add-on. The @NonNull annotation is the
perfect candidate that wants to migrate to TYPE_USE in Java 8.

My point is that there's no way @NonNull can be a declaration and a
type-use annotation at the same time, and both of these usages have the
same semantics. Yes, you can declare separate reflection APIs for
declaration and type-use annotations, but in the end, the compiler add-on
that implements the annotation's semantics needs to decide which one to
use. And it will show different behavior depending on the used API.
Disregarding the semantics of the annotation doesn't make sense. You can't
just look at the compiler and reflection APIs in isolation. You also have
consider who will use them.

The examples s4/s5 with the qualified name shows that it's not even
possible to use an @Target({ElementType.FIELD, ElementType.TYPE_USE})
annotation in certain cases that were legal with @Target
({ElementType.FIELD}) alone, since the two target kinds _require_ different
positions in the AST. Therefore, adding TYPE_USE is not a 100%
source-compatible change, even if you disregard the semantics of the
annotation.

The spec should not make it look like it's a valid transition path for an
existing declaration annotation type to add the TYPE_USE target. I would
even disallow this combination, since we haven't found a single use case
where it would make sense.

TYPE_USE should only be used as the sole @Target. Providers of Java 7
annotation types that want to migrate to TYPE_USE should make it clear that
this change is not for free for client code in all cases. That standpoint
also gives us the freedom to constrain TYPE_USE annotations to occur just
before the type.

Markus