[JSR308] Locations for annotations on types

[Neal Gafter]

On 2/25/07, Michael Ernst <mernst at csail.mit.edu> wrote:
>
> > A few obvious ones you missed, found while glancing through the Java
> > grammar:
> >
> >    - method return type (which is not the same thing as the method
> >    itself)
>
> This one is explicitly discussed in the document and supported.
>
> Some of the others make no sense, but thanks for pointing out that that
> wasn't obvious.  I'll update the document to so indicate, and raise
> discussions on the list where appropriate.


I don't know what you man "makes no sense".   It feels like, on the one
hand, we're trying to support annotations on types generally, but on the
other hand we're not trying to do any more than needed for the currently
recognized use cases.  Which is it?  The latter is a very dangerous approach
for what is supposed to be a general language facility (because people are
likely to soon find compelling use cases that we didn't anticipate).

> The draft spec notes that the currently selected syntax is ambiguous in
> the
> > first two cases (variable type and method return type)
>
> Actually, the draft proposal says that the meaning is *unambiguous* in
> those cases.  (A previous version incorrectly stated that the syntax is
> ambiguous.)


I quote (emphasis mine):

There is no need for new syntax for annotations on return types, because
Java already permits an annotation to appear before a method return type.
For example, in

    @Deprecated @NonNull Dimension getSize() { ... }

@Deprecated applies to the method and @NonNull applies to the return type.
When an annotation processor encounters an annotation in this position, it
can treat the annotation as applying to the method or to the return type, or
it can issue a warning/error if the annotation is not sensible in either
location. (The annotation processor can choose by using the
@Targetannotation that appears on the Java definitions of the
Deprecated and NonNull interfaces, or in some other way.) This design
assumes that there are few anotations that can apply equally well to both
methods and return value types, and that have different semantics in the two
situations. If such annotations are common, then a different syntax may be
warranted.
The first sentence says that annotating a return type is not necessary
because of the ambiguity, though it doesn't use the word ambiguity.  The
following text, though, is slightly more clear.  Whether it appears in the
specification or not, this is clearly a single syntax that can have two
meanings, and programs can be constructed in which both meanings would be
legal.  That is what the word "ambiguity" in language design means.  Saying
it is unambiguous doesn't make it so.

The discussion is at the end of section 3.1 in the current draft, for those
> who want to read it.  (Everyone who contributes to the discussions should
> do so, to keep discussions productive.)


Here's what I find at the end of section 3.1:

Not every type system (or other system using annotations) may utilize every
possible annotation location. For example, a system that fully specifies
type qualifiers in signatures but infers them for implementations
[GF05<http://pag.csail.mit.edu/jsr308/java-annotation-design.html#GreenfieldboyceF2005>]
may not need annotations on typecasts, object creation, local variables, or
certain other locations. Other systems may forbid top-level
(non-type-argument, non-array) annotations on object creation (new)
expressions, such as new @Interned Object(). However, the annotation system
proposed here is expressive enough to handle arbitrary type qualifiers.

Clearly, this is not the case in the presence of ambiguities, and it is not
the case if we exclude any of the places where types appear, as you appear
to be suggesting we should do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20070225/b77e7cad/attachment.html