[JSR308] Locations for annotations on types

[Neal Gafter]

On 2/25/07, Michael Ernst <mernst at csail.mit.edu> wrote:
>
> > "Method Receivers" are not a mention of a type
>
> They are an implicit mention of a type.  For example, the method
>
>   PrintStream.println(String)
>
> has two parameters.  Java provides a shorthand that permits one of them to
> be implicit, but both parameters should be able to be annotated.


Those are (actual) arguments, not (formal) parameters. In a class, the
receiver is always the class itself; the receiver is the same type for all
methods in a class.

> Rather than naming all the places that Type appears in the language
> grammar,
> > why not simply name the Type nonterminal?  That can reduce the list to
> > approximately one item.
>
> This is not responsive to my question.  We already have that short,
> one-element list.  I am asking what the expansion of it is.  That
> expansion
> is useful for testing, for defining the class file format (where
> source-level notion like "the Type nonterminal" are not relevant), for
> helping people to understand how the annotations can be used, and for
> other
> purposes.  So let's try to stick to that topic for now.


I'm not sure why you want the list expanded one level and not two or three.
The two-level expansion is in some contexts necessary for defining these
file formats as well.

Another member of the mailing list provided two specific, helpful examples:
>
>     * generic type arguments in a generic method or constructor invocation
>     * class literals
>
> I have added these to the design document.  Other such suggestions are
> welcome.


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)
   - a variable's declared type (which is not the same thing as the
   variable itself)
   - qualifier (of a qualified variable/type/method)
   - import declaration
   - the annotation type of an annotation
   - the conjuncts of a conjunctive bound

The draft spec notes that the currently selected syntax is ambiguous in the
first two cases (variable type and method return type) and from that fact
somehow concludes that these contexts are unnecessary to support (or that "a
different syntax may be warranted"). I don't really follow the flow of the
logic, but the result appears to be a gratuitous nonorthogonality. Am I to
understand that syntactic alternatives are no longer on the table?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20070225/ee2ad605/attachment-0001.htm