Constraining type annotations to occur just before type

[Srikanth S Adayapalam]

Yet more comments from the Eclipse JDT team.

Srikanth

--------------------------8<-----------------

Another example that shows the inconsistency is the different intended
semantics of annotations in multi-field declarations and union types in
catch clauses.

The @NonNull in the field declaration's modifiers list appears in the type
of "a" (@NonNull String) as well as in the type of "b" (array of (@NonNull
String)):

    @NonNull String a, b[];


But here, I would assume the @NonCritical in the modifiers list only
applies to the first type of the union:

    catch (final @NonCritical AccountException | @Critical AccessException
ex)

Note that the classfile format currently mixes the annotations of all union
types together into one EXCEPTION_PARAMETER entry for the catch variable.

-----------------------------------------------

The problem is that the JSR 308 only specifies positions in the source code
where annotations can appear, but it even says "it makes no commitment as
to their semantics". For a compiler that is only concerned about generating
class files, that's in most cases enough. But it makes it very hard for
language tooling to process these annotations in a sensible way.

> >     @NonNull String a, b[];
>
> And you are saying that is what a programmer would expect - right ?

Yes. In this case, JSR 308 2.2.1 tells that the @NonNull is used for both
variables. So it does attach some semantics to the annotation.


> > But here, I would assume the @NonCritical in the modifiers list only
applies
> > to the first type of the union:
> >
> >    catch (final @NonCritical AccountException | @Critical
AccessException ex)
>
> And by "I would assume" you are saying that this is what a programmer
would
> intuitively expect - right ?

Yes. But the spec doesn't say a word about the union type case. There's
just the table in 3.2 and section 3.3.8, from which we have to assume that
the annotations from all union types are collapsed into the same
EXCEPTION_PARAMETER target. If I can put different annotations on different
union type alternatives, then I would expect them to be treated separately.
Currently, the compilation cuts the connection from an EXCEPTION_PARAMETER
annotation to its type.

http://types.cs.washington.edu/jsr308/specification/java-annotation-extensions.html#locations-disjunctions
 also assumes that annotations only belong to their union type alternative.