From markus_keller at ch.ibm.com  Thu Feb  6 08:58:56 2014
From: markus_keller at ch.ibm.com (Markus Keller)
Date: Thu, 6 Feb 2014 17:58:56 +0100
Subject: type annotations on generic method return type
Message-ID: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>

java-se-8-jls-fr-diffs.pdf "9.7.4 Where Annotations May Appear" reads:
"It is possible for an annotation to appear at a syntactic location in a 
program where it could plausibly apply to a declaration, or a type, or 
both."

And later concerning type annotations: "[...] the annotation is deemed to 
apply only to the type which is closest to the annotation."

What about a generic method declaration, where a type parameter 
declaration "<T>" separates the method modifiers from the return type's 
type annotations?

    public @A <T> @B Set<T> foo(T t) { /*...*/ } 

=> If @A is a TYPE_USE annotation, is it also considered a type annotation 
in this case? Although its syntactic location does _not_ make it apply to 
the return type?

=> @B is _not_ syntactically legal according to the current grammar, since 
Result cannot start with an annotation:

MethodHeader:
        {MethodModifier} [TypeParameters] Result MethodDeclarator [Throws]

Result:
        UnannType
        void

Both javac and ecj currently accept the above declaration.


BTW: Note that term "closest" in "the type which is closest to the 
annotation" is not defined by the spec. Likewise, type annotations on 
array types are only defined in an informal section.
"Closest" seems to mean something like "the next following type reference 
that is not in an other annotation (and not in a type parameter 
declaration)".

Regards,
Markus


From markus_keller at ch.ibm.com  Thu Feb  6 08:59:40 2014
From: markus_keller at ch.ibm.com (Markus Keller)
Date: Thu, 6 Feb 2014 17:59:40 +0100
Subject: Recommended placement of type annotations
Message-ID: <OF463C7CA6.0E80BEA0-ONC1257C77.005588CC-C1257C77.005D5FC0@ch.ibm.com>

java-se-8-jls-fr-diffs.pdf says in 9.7.4: "It is customary, though not 
required, to place annotations before all other modifiers."
But that's not the tradition for type annotations.

The java-annotation-design.html said: "It is strongly recommended that 
type annotations be written immediately before the type, after declaration 
annotations and modifiers."

A more useful recommendation to alleviate the grammar problems is this:
=> "It is strongly recommended that declaration annotations be written 
before all other modifiers, and type annotations immediately before the 
type they apply to."

Regard,
Markus


From markus_keller at ch.ibm.com  Thu Feb  6 09:01:25 2014
From: markus_keller at ch.ibm.com (Markus Keller)
Date: Thu, 6 Feb 2014 18:01:25 +0100
Subject: TYPE_USE annotations in declaration contexts
Message-ID: <OF0C76BAA2.241BC55F-ONC1257C77.00556063-C1257C77.005D88C4@ch.ibm.com>

The Javadoc of java.lang.annotation.ElementType says: "The constant 
TYPE_USE corresponds to the 15 type contexts in JLS 4.11, as well as to 
two declaration contexts: type declarations (including annotation type 
declarations) and type parameter declarations."

java-se-8-jls-fr-diffs.pdf 9.6.4.1 says: "There are 15 type contexts 
(?4.11), all represented by the enum constant TYPE_USE of 
java.lang.annotation.ElementType."

=> JLS8 doesn't tell that TYPE_USE annotations are also applicable in two 
declaration contexts. This should be added to JLS8 9.6.4.1. 

Current implementations of javac and ecj follow the Javadoc (accept a 
TYPE_USE annotation on a type declaration) and thus violate the current 
JLS8.

Regards,
Markus


From mernst at cs.washington.edu  Thu Feb  6 09:15:17 2014
From: mernst at cs.washington.edu (Michael Ernst)
Date: Thu, 06 Feb 2014 09:15:17 -0800 (PST)
Subject: Recommended placement of type annotations
In-Reply-To: <OF463C7CA6.0E80BEA0-ONC1257C77.005588CC-C1257C77.005D5FC0@ch.ibm.com>
References: <OF463C7CA6.0E80BEA0-ONC1257C77.005588CC-C1257C77.005D5FC0@ch.ibm.com>
Message-ID: <20140206.091517.860047291258989040.mernst@cs.washington.edu>

I agree with this suggestion.  Thanks, Markus.

                    -Mike


> Subject: Recommended placement of type annotations
> From: Markus Keller <markus_keller at ch.ibm.com>
> To: type-annotations-spec-comments at openjdk.java.net
> Date: Thu, 6 Feb 2014 17:59:40 +0100
> 
> java-se-8-jls-fr-diffs.pdf says in 9.7.4: "It is customary, though not 
> required, to place annotations before all other modifiers."
> But that's not the tradition for type annotations.
> 
> The java-annotation-design.html said: "It is strongly recommended that 
> type annotations be written immediately before the type, after declaration 
> annotations and modifiers."
> 
> A more useful recommendation to alleviate the grammar problems is this:
> => "It is strongly recommended that declaration annotations be written 
> before all other modifiers, and type annotations immediately before the 
> type they apply to."
> 
> Regard,
> Markus

From alex.buckley at oracle.com  Thu Feb  6 11:55:35 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 06 Feb 2014 11:55:35 -0800
Subject: TYPE_USE annotations in declaration contexts
In-Reply-To: <OF0C76BAA2.241BC55F-ONC1257C77.00556063-C1257C77.005D88C4@ch.ibm.com>
References: <OF0C76BAA2.241BC55F-ONC1257C77.00556063-C1257C77.005D88C4@ch.ibm.com>
Message-ID: <52F3E8B7.4090500@oracle.com>

The goal of 9.6.4.1 is not to mirror the javadoc text, but to formally 
introduce _declaration contexts_ and _type contexts_ for the benefit of 
9.7.4 and 9.7.5. The contexts are introduced in 9.6.4.1 so that the 
javadoc can also rely on them when specifying how @Target(TYPE), 
@Target(TYPE_USE), etc, are interpreted. 9.6.4.1 doesn't actually 
specify @Target(TYPE_USE).

Alex

On 2/6/2014 9:01 AM, Markus Keller wrote:
> The Javadoc of java.lang.annotation.ElementType says: "The constant
> TYPE_USE corresponds to the 15 type contexts in JLS 4.11, as well as to
> two declaration contexts: type declarations (including annotation type
> declarations) and type parameter declarations."
>
> java-se-8-jls-fr-diffs.pdf 9.6.4.1 says: "There are 15 type contexts
> (?4.11), all represented by the enum constant TYPE_USE of
> java.lang.annotation.ElementType."
>
> => JLS8 doesn't tell that TYPE_USE annotations are also applicable in two
> declaration contexts. This should be added to JLS8 9.6.4.1.
>
> Current implementations of javac and ecj follow the Javadoc (accept a
> TYPE_USE annotation on a type declaration) and thus violate the current
> JLS8.
>
> Regards,
> Markus
>

From alex.buckley at oracle.com  Thu Feb  6 12:29:03 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 06 Feb 2014 12:29:03 -0800
Subject: Recommended placement of type annotations
In-Reply-To: <20140206.091517.860047291258989040.mernst@cs.washington.edu>
References: <OF463C7CA6.0E80BEA0-ONC1257C77.005588CC-C1257C77.005D5FC0@ch.ibm.com>
	<20140206.091517.860047291258989040.mernst@cs.washington.edu>
Message-ID: <52F3F08F.4000209@oracle.com>

OK.

On 2/6/2014 9:15 AM, Michael Ernst wrote:
> I agree with this suggestion.  Thanks, Markus.
>
>                      -Mike
>
>
>> Subject: Recommended placement of type annotations
>> From: Markus Keller <markus_keller at ch.ibm.com>
>> To: type-annotations-spec-comments at openjdk.java.net
>> Date: Thu, 6 Feb 2014 17:59:40 +0100
>>
>> java-se-8-jls-fr-diffs.pdf says in 9.7.4: "It is customary, though not
>> required, to place annotations before all other modifiers."
>> But that's not the tradition for type annotations.
>>
>> The java-annotation-design.html said: "It is strongly recommended that
>> type annotations be written immediately before the type, after declaration
>> annotations and modifiers."
>>
>> A more useful recommendation to alleviate the grammar problems is this:
>> => "It is strongly recommended that declaration annotations be written
>> before all other modifiers, and type annotations immediately before the
>> type they apply to."
>>
>> Regard,
>> Markus

From alex.buckley at oracle.com  Thu Feb  6 15:43:27 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 06 Feb 2014 15:43:27 -0800
Subject: type annotations on generic method return type
In-Reply-To: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>
References: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>
Message-ID: <52F41E1F.1060408@oracle.com>

First of two mails. Not good news in this one.

On 2/6/2014 8:58 AM, Markus Keller wrote:
> What about a generic method declaration, where a type parameter
> declaration "<T>" separates the method modifiers from the return type's
> type annotations?
>
>      public @A <T> @B Set<T> foo(T t) { /*...*/ }
>
> => @B is _not_ syntactically legal according to the current grammar, since
> Result cannot start with an annotation:
>
> MethodHeader:
>          {MethodModifier} [TypeParameters] Result MethodDeclarator [Throws]
>
> Result:
>          UnannType
>          void
>
> Both javac and ecj currently accept the above declaration.

The original 308 spec (java-annotation-design.pdf) didn't address 
generic method declarations. Here are the relevant productions from JLS7 
ch.18:

ClassBodyDeclaration:
   ...
   {Modifier} MemberDecl

MemberDecl:
   GenericMethodOrConstructorDecl  // Not modified by 308
   MethodOrFieldDecl               // Modified by 308
   ...

// Modified by 308
MethodOrFieldDecl:
   UnannType Identifier MethodOrFieldRest

// Not modified by 308
GenericMethodOrConstructorDecl:
   TypeParameters GenericMethodOrConstructorRest

GenericMethodOrConstructorRest:
   (Type | void) Identifier MethodDeclaratorRest
   ...

Type:
   [Annotations] UnannType

The effect was to allow @B after the type parameter section:

   public <T> @B Set<T> foo(...) {...}

and of course @A as a modifier before the type parameter section:

   public @A <T> Set<T> foo(...) {...}

Ordinarily, I would change JLS8 to agree with that intent (albeit rather 
subtle) and with the behavior of both compilers. That is, I would regard 
this whole topic as a minor spec integration problem.

Unfortunately, JLS8 cannot be cleanly changed. The problem is the ch.8 
grammar for MethodHeader, distinct from the old ch.18 grammar. We cannot 
change MethodHeader to:

MethodHeader:
   {MethodModifier} [TypeParameters] {Annotation} Result ...

because, without no type parameters present, any annotations immediately 
to the left of Result would be ambiguous.

I am therefore going to leave JLS8 as-is, and ask both compilers to 
reject the @B after the type parameter section.

Alex

From alex.buckley at oracle.com  Thu Feb  6 15:58:15 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 06 Feb 2014 15:58:15 -0800
Subject: type annotations on generic method return type
In-Reply-To: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>
References: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>
Message-ID: <52F42197.2040603@oracle.com>

Second of two mails. No real surprises here.

On 2/6/2014 8:58 AM, Markus Keller wrote:
> What about a generic method declaration, where a type parameter
> declaration "<T>" separates the method modifiers from the return type's
> type annotations?
>
>      public @A <T> @B Set<T> foo(T t) { /*...*/ }
>
> => If @A is a TYPE_USE annotation, is it also considered a type annotation
> in this case? Although its syntactic location does _not_ make it apply to
> the return type?

@A is unambiguously parsed as a MethodModifier, but (ignoring the type 
parameter section) it could plausibly apply to the declaration of method 
foo or the return type of method foo. Which is it? JLS 9.7.4 says:

"If the annotation's type is applicable in type contexts, and not in the 
declaration context corresponding to the declaration, then the 
annotation is deemed to apply only to the type which is closest to the 
annotation."

So, assuming the declaration of A has just @Target(TYPE_USE), @A applies 
only to the closest type, Set<T>. (Again ignoring the type parameter 
section.) In turn, that makes @A a type annotation:

"A type annotation is an annotation that applies to a type (or any part 
of a type), and whose own type is applicable in type contexts (?4.11)."

> BTW: Note that term "closest" in "the type which is closest to the
> annotation" is not defined by the spec. Likewise, type annotations on
> array types are only defined in an informal section.
> "Closest" seems to mean something like "the next following type reference
> that is not in an other annotation (and not in a type parameter
> declaration)".

I don't think "closest" is terribly confusing, even with a type 
parameter section, but I agree the text can do better:

"If the annotation's type is applicable in type contexts, and not in the 
declaration context corresponding to the declaration, then the 
annotation is deemed to apply only to _the type of the declared entity_."

Alex

From alex.buckley at oracle.com  Thu Feb  6 16:01:53 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 06 Feb 2014 16:01:53 -0800
Subject: [type-annos-observers] type annotations on generic method return
	type
In-Reply-To: <52F421DF.4060803@gmail.com>
References: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>
	<52F41E1F.1060408@oracle.com> <52F421DF.4060803@gmail.com>
Message-ID: <52F42271.9020708@oracle.com>

No, I meant "reject the @B". If you want it to be accepted, please 
provide an unambiguous JLS grammar for MethodHeader.

Alex

On 2/6/2014 3:59 PM, Werner Dietl wrote:
> Alex,
>
> In your last sentence:
>
>> I am therefore going to leave JLS8 as-is, and ask both compilers to
>> reject the @B after the type parameter section.
>
> don't you mean "accept the @B"?
> It would be quite ugly if we had to separate a type annotation on the
> return type by the type parameter section.
>
> cu, WMD.
>
>
> On 02/06/2014 06:43 PM, Alex Buckley wrote:
>> First of two mails. Not good news in this one.
>>
>> On 2/6/2014 8:58 AM, Markus Keller wrote:
>>> What about a generic method declaration, where a type parameter
>>> declaration "<T>" separates the method modifiers from the return type's
>>> type annotations?
>>>
>>>       public @A <T> @B Set<T> foo(T t) { /*...*/ }
>>>
>>> => @B is _not_ syntactically legal according to the current grammar,
>>> since
>>> Result cannot start with an annotation:
>>>
>>> MethodHeader:
>>>           {MethodModifier} [TypeParameters] Result MethodDeclarator
>>> [Throws]
>>>
>>> Result:
>>>           UnannType
>>>           void
>>>
>>> Both javac and ecj currently accept the above declaration.
>>
>> The original 308 spec (java-annotation-design.pdf) didn't address
>> generic method declarations. Here are the relevant productions from JLS7
>> ch.18:
>>
>> ClassBodyDeclaration:
>>    ...
>>    {Modifier} MemberDecl
>>
>> MemberDecl:
>>    GenericMethodOrConstructorDecl  // Not modified by 308
>>    MethodOrFieldDecl               // Modified by 308
>>    ...
>>
>> // Modified by 308
>> MethodOrFieldDecl:
>>    UnannType Identifier MethodOrFieldRest
>>
>> // Not modified by 308
>> GenericMethodOrConstructorDecl:
>>    TypeParameters GenericMethodOrConstructorRest
>>
>> GenericMethodOrConstructorRest:
>>    (Type | void) Identifier MethodDeclaratorRest
>>    ...
>>
>> Type:
>>    [Annotations] UnannType
>>
>> The effect was to allow @B after the type parameter section:
>>
>>    public <T> @B Set<T> foo(...) {...}
>>
>> and of course @A as a modifier before the type parameter section:
>>
>>    public @A <T> Set<T> foo(...) {...}
>>
>> Ordinarily, I would change JLS8 to agree with that intent (albeit rather
>> subtle) and with the behavior of both compilers. That is, I would regard
>> this whole topic as a minor spec integration problem.
>>
>> Unfortunately, JLS8 cannot be cleanly changed. The problem is the ch.8
>> grammar for MethodHeader, distinct from the old ch.18 grammar. We cannot
>> change MethodHeader to:
>>
>> MethodHeader:
>>    {MethodModifier} [TypeParameters] {Annotation} Result ...
>>
>> because, without no type parameters present, any annotations immediately
>> to the left of Result would be ambiguous.
>>
>> I am therefore going to leave JLS8 as-is, and ask both compilers to
>> reject the @B after the type parameter section.
>>
>> Alex

From wdietl at gmail.com  Thu Feb  6 17:10:01 2014
From: wdietl at gmail.com (Werner Dietl)
Date: Thu, 6 Feb 2014 20:10:01 -0500
Subject: [type-annos-observers] type annotations on generic method return
	type
In-Reply-To: <52F42271.9020708@oracle.com>
References: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>
	<52F41E1F.1060408@oracle.com> <52F421DF.4060803@gmail.com>
	<52F42271.9020708@oracle.com>
Message-ID: <CAJYRO=5991yzhzS6-ra01a+RfNKLE0Udpm1gK99KARmUqR3H9w@mail.gmail.com>

What would be bad about this:

MethodHeader:
  {MethodModifier} Result MethodDeclarator [Throws]
  {MethodModifier} TypeParameters {Annotation} Result MethodDeclarator [Throws]

If you don't like the "Result MethodDeclarator [Throws]" duplication,
you could introduce a MethodHeaderRest for it.

But maybe I misunderstand what ambiguity you mean.

cu, WMD.


On Thu, Feb 6, 2014 at 7:01 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> No, I meant "reject the @B". If you want it to be accepted, please provide
> an unambiguous JLS grammar for MethodHeader.
>
> Alex
>
>
> On 2/6/2014 3:59 PM, Werner Dietl wrote:
>>
>> Alex,
>>
>> In your last sentence:
>>
>>> I am therefore going to leave JLS8 as-is, and ask both compilers to
>>> reject the @B after the type parameter section.
>>
>>
>> don't you mean "accept the @B"?
>> It would be quite ugly if we had to separate a type annotation on the
>> return type by the type parameter section.
>>
>> cu, WMD.
>>
>>
>> On 02/06/2014 06:43 PM, Alex Buckley wrote:
>>>
>>> First of two mails. Not good news in this one.
>>>
>>> On 2/6/2014 8:58 AM, Markus Keller wrote:
>>>>
>>>> What about a generic method declaration, where a type parameter
>>>> declaration "<T>" separates the method modifiers from the return type's
>>>> type annotations?
>>>>
>>>>       public @A <T> @B Set<T> foo(T t) { /*...*/ }
>>>>
>>>> => @B is _not_ syntactically legal according to the current grammar,
>>>> since
>>>> Result cannot start with an annotation:
>>>>
>>>> MethodHeader:
>>>>           {MethodModifier} [TypeParameters] Result MethodDeclarator
>>>> [Throws]
>>>>
>>>> Result:
>>>>           UnannType
>>>>           void
>>>>
>>>> Both javac and ecj currently accept the above declaration.
>>>
>>>
>>> The original 308 spec (java-annotation-design.pdf) didn't address
>>> generic method declarations. Here are the relevant productions from JLS7
>>> ch.18:
>>>
>>> ClassBodyDeclaration:
>>>    ...
>>>    {Modifier} MemberDecl
>>>
>>> MemberDecl:
>>>    GenericMethodOrConstructorDecl  // Not modified by 308
>>>    MethodOrFieldDecl               // Modified by 308
>>>    ...
>>>
>>> // Modified by 308
>>> MethodOrFieldDecl:
>>>    UnannType Identifier MethodOrFieldRest
>>>
>>> // Not modified by 308
>>> GenericMethodOrConstructorDecl:
>>>    TypeParameters GenericMethodOrConstructorRest
>>>
>>> GenericMethodOrConstructorRest:
>>>    (Type | void) Identifier MethodDeclaratorRest
>>>    ...
>>>
>>> Type:
>>>    [Annotations] UnannType
>>>
>>> The effect was to allow @B after the type parameter section:
>>>
>>>    public <T> @B Set<T> foo(...) {...}
>>>
>>> and of course @A as a modifier before the type parameter section:
>>>
>>>    public @A <T> Set<T> foo(...) {...}
>>>
>>> Ordinarily, I would change JLS8 to agree with that intent (albeit rather
>>> subtle) and with the behavior of both compilers. That is, I would regard
>>> this whole topic as a minor spec integration problem.
>>>
>>> Unfortunately, JLS8 cannot be cleanly changed. The problem is the ch.8
>>> grammar for MethodHeader, distinct from the old ch.18 grammar. We cannot
>>> change MethodHeader to:
>>>
>>> MethodHeader:
>>>    {MethodModifier} [TypeParameters] {Annotation} Result ...
>>>
>>> because, without no type parameters present, any annotations immediately
>>> to the left of Result would be ambiguous.
>>>
>>> I am therefore going to leave JLS8 as-is, and ask both compilers to
>>> reject the @B after the type parameter section.
>>>
>>> Alex



-- 
http://www.google.com/profiles/wdietl

From alex.buckley at oracle.com  Thu Feb  6 18:50:38 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 06 Feb 2014 18:50:38 -0800
Subject: [type-annos-observers] type annotations on generic method return
	type
In-Reply-To: <CAJYRO=5991yzhzS6-ra01a+RfNKLE0Udpm1gK99KARmUqR3H9w@mail.gmail.com>
References: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>
	<52F41E1F.1060408@oracle.com> <52F421DF.4060803@gmail.com>
	<52F42271.9020708@oracle.com>
	<CAJYRO=5991yzhzS6-ra01a+RfNKLE0Udpm1gK99KARmUqR3H9w@mail.gmail.com>
Message-ID: <52F449FE.2030705@oracle.com>

I guess that works. Shades of MethodDeclarator - "Huh? There's an 
{Annotation} nonterminal _there_?" - but it does the job. Good catch!

I'd be inclined to pull MethodModifier up:

MethodDeclaration:
   {MethodModifier} MethodHeader MethodBody

MethodHeader:
   Result MethodDeclarator [Throws]
   TypeParameters {Annotation} Result MethodDeclarator [Throws]

because that's more consistent with ClassDeclaration, FieldDeclaration, 
et al. "Method header" may be an informal phrase in conversation, but 
it's not actually used in the text.

Alex

On 2/6/2014 5:10 PM, Werner Dietl wrote:
> What would be bad about this:
>
> MethodHeader:
>    {MethodModifier} Result MethodDeclarator [Throws]
>    {MethodModifier} TypeParameters {Annotation} Result MethodDeclarator [Throws]
>
> If you don't like the "Result MethodDeclarator [Throws]" duplication,
> you could introduce a MethodHeaderRest for it.
>
> But maybe I misunderstand what ambiguity you mean.
>
> cu, WMD.
>
>
> On Thu, Feb 6, 2014 at 7:01 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
>> No, I meant "reject the @B". If you want it to be accepted, please provide
>> an unambiguous JLS grammar for MethodHeader.
>>
>> Alex
>>
>>
>> On 2/6/2014 3:59 PM, Werner Dietl wrote:
>>>
>>> Alex,
>>>
>>> In your last sentence:
>>>
>>>> I am therefore going to leave JLS8 as-is, and ask both compilers to
>>>> reject the @B after the type parameter section.
>>>
>>>
>>> don't you mean "accept the @B"?
>>> It would be quite ugly if we had to separate a type annotation on the
>>> return type by the type parameter section.
>>>
>>> cu, WMD.
>>>
>>>
>>> On 02/06/2014 06:43 PM, Alex Buckley wrote:
>>>>
>>>> First of two mails. Not good news in this one.
>>>>
>>>> On 2/6/2014 8:58 AM, Markus Keller wrote:
>>>>>
>>>>> What about a generic method declaration, where a type parameter
>>>>> declaration "<T>" separates the method modifiers from the return type's
>>>>> type annotations?
>>>>>
>>>>>        public @A <T> @B Set<T> foo(T t) { /*...*/ }
>>>>>
>>>>> => @B is _not_ syntactically legal according to the current grammar,
>>>>> since
>>>>> Result cannot start with an annotation:
>>>>>
>>>>> MethodHeader:
>>>>>            {MethodModifier} [TypeParameters] Result MethodDeclarator
>>>>> [Throws]
>>>>>
>>>>> Result:
>>>>>            UnannType
>>>>>            void
>>>>>
>>>>> Both javac and ecj currently accept the above declaration.
>>>>
>>>>
>>>> The original 308 spec (java-annotation-design.pdf) didn't address
>>>> generic method declarations. Here are the relevant productions from JLS7
>>>> ch.18:
>>>>
>>>> ClassBodyDeclaration:
>>>>     ...
>>>>     {Modifier} MemberDecl
>>>>
>>>> MemberDecl:
>>>>     GenericMethodOrConstructorDecl  // Not modified by 308
>>>>     MethodOrFieldDecl               // Modified by 308
>>>>     ...
>>>>
>>>> // Modified by 308
>>>> MethodOrFieldDecl:
>>>>     UnannType Identifier MethodOrFieldRest
>>>>
>>>> // Not modified by 308
>>>> GenericMethodOrConstructorDecl:
>>>>     TypeParameters GenericMethodOrConstructorRest
>>>>
>>>> GenericMethodOrConstructorRest:
>>>>     (Type | void) Identifier MethodDeclaratorRest
>>>>     ...
>>>>
>>>> Type:
>>>>     [Annotations] UnannType
>>>>
>>>> The effect was to allow @B after the type parameter section:
>>>>
>>>>     public <T> @B Set<T> foo(...) {...}
>>>>
>>>> and of course @A as a modifier before the type parameter section:
>>>>
>>>>     public @A <T> Set<T> foo(...) {...}
>>>>
>>>> Ordinarily, I would change JLS8 to agree with that intent (albeit rather
>>>> subtle) and with the behavior of both compilers. That is, I would regard
>>>> this whole topic as a minor spec integration problem.
>>>>
>>>> Unfortunately, JLS8 cannot be cleanly changed. The problem is the ch.8
>>>> grammar for MethodHeader, distinct from the old ch.18 grammar. We cannot
>>>> change MethodHeader to:
>>>>
>>>> MethodHeader:
>>>>     {MethodModifier} [TypeParameters] {Annotation} Result ...
>>>>
>>>> because, without no type parameters present, any annotations immediately
>>>> to the left of Result would be ambiguous.
>>>>
>>>> I am therefore going to leave JLS8 as-is, and ask both compilers to
>>>> reject the @B after the type parameter section.
>>>>
>>>> Alex
>
>
>

From markus_keller at ch.ibm.com  Fri Feb  7 02:51:11 2014
From: markus_keller at ch.ibm.com (Markus Keller)
Date: Fri, 7 Feb 2014 11:51:11 +0100
Subject: [type-annos-observers] type annotations on generic
	method	return	type
In-Reply-To: <52F449FE.2030705@oracle.com>
References: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>	<52F41E1F.1060408@oracle.com>
	<52F421DF.4060803@gmail.com>
	<52F42271.9020708@oracle.com>	<CAJYRO=5991yzhzS6-ra01a+RfNKLE0Udpm1gK99KARmUqR3H9w@mail.gmail.com>
	<52F449FE.2030705@oracle.com>
Message-ID: <OFEE08E8F0.215B0B1D-ONC1257C78.00385073-C1257C78.003BA33B@ch.ibm.com>

Thanks Werner and Alex. I fully agree @B should be legal, and the proposed 
grammar looks OK to me.

Note that InterfaceMethodDeclaration needs the same treatment:

InterfaceMethodDeclaration:
   {InterfaceMethodModifier} Result MethodDeclarator [Throws] MethodBody
   {InterfaceMethodModifier} TypeParameters {Annotation} Result 
MethodDeclarator [Throws] MethodBody


An alternative would be to move TypeParameters into Result, but I couldn't 
find a good name for the nonterminal:

MethodHeader:
   {MethodModifier} TypeParametersAndResult MethodDeclarator [Throws]

InterfaceMethodDeclaration:
   {InterfaceMethodModifier} TypeParametersAndResult MethodDeclarator 
[Throws] MethodBody

TypeParametersAndResult:
   TypeParameters {Annotation} UnannType
   UnannType
   [TypeParameters] void

Although I still don't see a relevant use case for @A, I guess it makes 
sense to keep that legal (since the JLS also allows type annotations in 
similarly disconnected locations in other kinds of declarations).

Markus

Alex Buckley <alex.buckley at oracle.com> wrote on 2014-02-07 03:50:38:
> From: Alex Buckley <alex.buckley at oracle.com>
> To: Werner Dietl <wdietl at gmail.com>
> Cc: type-annotations-spec-comments at openjdk.java.net
> Date: 2014-02-07 03:52
> Subject: Re: [type-annos-observers] type annotations on generic method 
return type
> Sent by: type-annotations-spec-observers-bounces at openjdk.java.net
> 
> I guess that works. Shades of MethodDeclarator - "Huh? There's an 
> {Annotation} nonterminal _there_?" - but it does the job. Good catch!
> 
> I'd be inclined to pull MethodModifier up:
> 
> MethodDeclaration:
>    {MethodModifier} MethodHeader MethodBody
> 
> MethodHeader:
>    Result MethodDeclarator [Throws]
>    TypeParameters {Annotation} Result MethodDeclarator [Throws]
> 
> because that's more consistent with ClassDeclaration, FieldDeclaration, 
> et al. "Method header" may be an informal phrase in conversation, but 
> it's not actually used in the text.
> 
> Alex
> 
> On 2/6/2014 5:10 PM, Werner Dietl wrote:
> > What would be bad about this:
> >
> > MethodHeader:
> >    {MethodModifier} Result MethodDeclarator [Throws]
> >    {MethodModifier} TypeParameters {Annotation} Result 
MethodDeclarator [Throws]
> >
> > If you don't like the "Result MethodDeclarator [Throws]" duplication,
> > you could introduce a MethodHeaderRest for it.
> >
> > But maybe I misunderstand what ambiguity you mean.
> >
> > cu, WMD.
> >
> >
> > On Thu, Feb 6, 2014 at 7:01 PM, Alex Buckley <alex.buckley at oracle.com> 
wrote:
> >> No, I meant "reject the @B". If you want it to be accepted, please 
provide
> >> an unambiguous JLS grammar for MethodHeader.
> >>
> >> Alex
> >>
> >>
> >> On 2/6/2014 3:59 PM, Werner Dietl wrote:
> >>>
> >>> Alex,
> >>>
> >>> In your last sentence:
> >>>
> >>>> I am therefore going to leave JLS8 as-is, and ask both compilers to
> >>>> reject the @B after the type parameter section.
> >>>
> >>>
> >>> don't you mean "accept the @B"?
> >>> It would be quite ugly if we had to separate a type annotation on 
the
> >>> return type by the type parameter section.
> >>>
> >>> cu, WMD.
> >>>
> >>>
> >>> On 02/06/2014 06:43 PM, Alex Buckley wrote:
> >>>>
> >>>> First of two mails. Not good news in this one.
> >>>>
> >>>> On 2/6/2014 8:58 AM, Markus Keller wrote:
> >>>>>
> >>>>> What about a generic method declaration, where a type parameter
> >>>>> declaration "<T>" separates the method modifiers from the return 
type's
> >>>>> type annotations?
> >>>>>
> >>>>>        public @A <T> @B Set<T> foo(T t) { /*...*/ }
> >>>>>
> >>>>> => @B is _not_ syntactically legal according to the current 
grammar,
> >>>>> since
> >>>>> Result cannot start with an annotation:
> >>>>>
> >>>>> MethodHeader:
> >>>>>            {MethodModifier} [TypeParameters] Result 
MethodDeclarator
> >>>>> [Throws]
> >>>>>
> >>>>> Result:
> >>>>>            UnannType
> >>>>>            void
> >>>>>
> >>>>> Both javac and ecj currently accept the above declaration.
> >>>>
> >>>>
> >>>> The original 308 spec (java-annotation-design.pdf) didn't address
> >>>> generic method declarations. Here are the relevant productions from 
JLS7
> >>>> ch.18:
> >>>>
> >>>> ClassBodyDeclaration:
> >>>>     ...
> >>>>     {Modifier} MemberDecl
> >>>>
> >>>> MemberDecl:
> >>>>     GenericMethodOrConstructorDecl  // Not modified by 308
> >>>>     MethodOrFieldDecl               // Modified by 308
> >>>>     ...
> >>>>
> >>>> // Modified by 308
> >>>> MethodOrFieldDecl:
> >>>>     UnannType Identifier MethodOrFieldRest
> >>>>
> >>>> // Not modified by 308
> >>>> GenericMethodOrConstructorDecl:
> >>>>     TypeParameters GenericMethodOrConstructorRest
> >>>>
> >>>> GenericMethodOrConstructorRest:
> >>>>     (Type | void) Identifier MethodDeclaratorRest
> >>>>     ...
> >>>>
> >>>> Type:
> >>>>     [Annotations] UnannType
> >>>>
> >>>> The effect was to allow @B after the type parameter section:
> >>>>
> >>>>     public <T> @B Set<T> foo(...) {...}
> >>>>
> >>>> and of course @A as a modifier before the type parameter section:
> >>>>
> >>>>     public @A <T> Set<T> foo(...) {...}
> >>>>
> >>>> Ordinarily, I would change JLS8 to agree with that intent (albeit 
rather
> >>>> subtle) and with the behavior of both compilers. That is, I would 
regard
> >>>> this whole topic as a minor spec integration problem.
> >>>>
> >>>> Unfortunately, JLS8 cannot be cleanly changed. The problem is the 
ch.8
> >>>> grammar for MethodHeader, distinct from the old ch.18 grammar. We 
cannot
> >>>> change MethodHeader to:
> >>>>
> >>>> MethodHeader:
> >>>>     {MethodModifier} [TypeParameters] {Annotation} Result ...
> >>>>
> >>>> because, without no type parameters present, any annotations 
immediately
> >>>> to the left of Result would be ambiguous.
> >>>>
> >>>> I am therefore going to leave JLS8 as-is, and ask both compilers to
> >>>> reject the @B after the type parameter section.
> >>>>
> >>>> Alex
> >
> >
> >
> 


From markus_keller at ch.ibm.com  Fri Feb  7 03:19:19 2014
From: markus_keller at ch.ibm.com (Markus Keller)
Date: Fri, 7 Feb 2014 12:19:19 +0100
Subject: type closest to a type annotation
In-Reply-To: <52F42197.2040603@oracle.com>
References: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>
	<52F42197.2040603@oracle.com>
Message-ID: <OFFCEDA0BC.6699DFAB-ONC1257C78.003BBAED-C1257C78.003E36AA@ch.ibm.com>

Alex Buckley <alex.buckley at oracle.com> wrote on 2014-02-07 00:58:15:
> On 2/6/2014 8:58 AM, Markus Keller wrote:
> > BTW: Note that term "closest" in "the type which is closest to the
> > annotation" is not defined by the spec. Likewise, type annotations on
> > array types are only defined in an informal section.
> > "Closest" seems to mean something like "the next following type 
reference
> > that is not in an other annotation (and not in a type parameter
> > declaration)".
> 
> I don't think "closest" is terribly confusing, even with a type 
> parameter section, but I agree the text can do better:
> 
> "If the annotation's type is applicable in type contexts, and not in the 

> declaration context corresponding to the declaration, then the 
> annotation is deemed to apply only to _the type of the declared 
entity_."

Then we better keep "closest". Counterexample:

    @A int[] f;

"The type of the declared entity" here means "the type of variable 'f'", 
which is "int[]", but the type annotation @A applies to "int".

But maybe you could add this sentence at the first occurrence of "closest" 
in 9.7.4?

"The closest type is the lexically first type reference in the declared 
entity's type."

Markus


From alex.buckley at oracle.com  Fri Feb  7 13:29:07 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 07 Feb 2014 13:29:07 -0800
Subject: [type-annos-observers] type annotations on generic method	return
	type
In-Reply-To: <OFEE08E8F0.215B0B1D-ONC1257C78.00385073-C1257C78.003BA33B@ch.ibm.com>
References: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>	<52F41E1F.1060408@oracle.com>
	<52F421DF.4060803@gmail.com>
	<52F42271.9020708@oracle.com>	<CAJYRO=5991yzhzS6-ra01a+RfNKLE0Udpm1gK99KARmUqR3H9w@mail.gmail.com>
	<52F449FE.2030705@oracle.com>
	<OFEE08E8F0.215B0B1D-ONC1257C78.00385073-C1257C78.003BA33B@ch.ibm.com>
Message-ID: <52F55023.7090107@oracle.com>

Since MethodHeader has been improved, it's possible to say simply:

InterfaceMethodDeclaration:
   {InterfaceMethodModifier} MethodHeader MethodBody

which is pleasingly consistent with MethodDeclaration.

Alex

On 2/7/2014 2:51 AM, Markus Keller wrote:
> Thanks Werner and Alex. I fully agree @B should be legal, and the proposed
> grammar looks OK to me.
>
> Note that InterfaceMethodDeclaration needs the same treatment:
>
> InterfaceMethodDeclaration:
>     {InterfaceMethodModifier} Result MethodDeclarator [Throws] MethodBody
>     {InterfaceMethodModifier} TypeParameters {Annotation} Result
> MethodDeclarator [Throws] MethodBody
>
>
> An alternative would be to move TypeParameters into Result, but I couldn't
> find a good name for the nonterminal:
>
> MethodHeader:
>     {MethodModifier} TypeParametersAndResult MethodDeclarator [Throws]
>
> InterfaceMethodDeclaration:
>     {InterfaceMethodModifier} TypeParametersAndResult MethodDeclarator
> [Throws] MethodBody
>
> TypeParametersAndResult:
>     TypeParameters {Annotation} UnannType
>     UnannType
>     [TypeParameters] void
>
> Although I still don't see a relevant use case for @A, I guess it makes
> sense to keep that legal (since the JLS also allows type annotations in
> similarly disconnected locations in other kinds of declarations).
>
> Markus
>
> Alex Buckley <alex.buckley at oracle.com> wrote on 2014-02-07 03:50:38:
>> From: Alex Buckley <alex.buckley at oracle.com>
>> To: Werner Dietl <wdietl at gmail.com>
>> Cc: type-annotations-spec-comments at openjdk.java.net
>> Date: 2014-02-07 03:52
>> Subject: Re: [type-annos-observers] type annotations on generic method
> return type
>> Sent by: type-annotations-spec-observers-bounces at openjdk.java.net
>>
>> I guess that works. Shades of MethodDeclarator - "Huh? There's an
>> {Annotation} nonterminal _there_?" - but it does the job. Good catch!
>>
>> I'd be inclined to pull MethodModifier up:
>>
>> MethodDeclaration:
>>     {MethodModifier} MethodHeader MethodBody
>>
>> MethodHeader:
>>     Result MethodDeclarator [Throws]
>>     TypeParameters {Annotation} Result MethodDeclarator [Throws]
>>
>> because that's more consistent with ClassDeclaration, FieldDeclaration,
>> et al. "Method header" may be an informal phrase in conversation, but
>> it's not actually used in the text.
>>
>> Alex
>>
>> On 2/6/2014 5:10 PM, Werner Dietl wrote:
>>> What would be bad about this:
>>>
>>> MethodHeader:
>>>     {MethodModifier} Result MethodDeclarator [Throws]
>>>     {MethodModifier} TypeParameters {Annotation} Result
> MethodDeclarator [Throws]
>>>
>>> If you don't like the "Result MethodDeclarator [Throws]" duplication,
>>> you could introduce a MethodHeaderRest for it.
>>>
>>> But maybe I misunderstand what ambiguity you mean.
>>>
>>> cu, WMD.
>>>
>>>
>>> On Thu, Feb 6, 2014 at 7:01 PM, Alex Buckley <alex.buckley at oracle.com>
> wrote:
>>>> No, I meant "reject the @B". If you want it to be accepted, please
> provide
>>>> an unambiguous JLS grammar for MethodHeader.
>>>>
>>>> Alex
>>>>
>>>>
>>>> On 2/6/2014 3:59 PM, Werner Dietl wrote:
>>>>>
>>>>> Alex,
>>>>>
>>>>> In your last sentence:
>>>>>
>>>>>> I am therefore going to leave JLS8 as-is, and ask both compilers to
>>>>>> reject the @B after the type parameter section.
>>>>>
>>>>>
>>>>> don't you mean "accept the @B"?
>>>>> It would be quite ugly if we had to separate a type annotation on
> the
>>>>> return type by the type parameter section.
>>>>>
>>>>> cu, WMD.
>>>>>
>>>>>
>>>>> On 02/06/2014 06:43 PM, Alex Buckley wrote:
>>>>>>
>>>>>> First of two mails. Not good news in this one.
>>>>>>
>>>>>> On 2/6/2014 8:58 AM, Markus Keller wrote:
>>>>>>>
>>>>>>> What about a generic method declaration, where a type parameter
>>>>>>> declaration "<T>" separates the method modifiers from the return
> type's
>>>>>>> type annotations?
>>>>>>>
>>>>>>>         public @A <T> @B Set<T> foo(T t) { /*...*/ }
>>>>>>>
>>>>>>> => @B is _not_ syntactically legal according to the current
> grammar,
>>>>>>> since
>>>>>>> Result cannot start with an annotation:
>>>>>>>
>>>>>>> MethodHeader:
>>>>>>>             {MethodModifier} [TypeParameters] Result
> MethodDeclarator
>>>>>>> [Throws]
>>>>>>>
>>>>>>> Result:
>>>>>>>             UnannType
>>>>>>>             void
>>>>>>>
>>>>>>> Both javac and ecj currently accept the above declaration.
>>>>>>
>>>>>>
>>>>>> The original 308 spec (java-annotation-design.pdf) didn't address
>>>>>> generic method declarations. Here are the relevant productions from
> JLS7
>>>>>> ch.18:
>>>>>>
>>>>>> ClassBodyDeclaration:
>>>>>>      ...
>>>>>>      {Modifier} MemberDecl
>>>>>>
>>>>>> MemberDecl:
>>>>>>      GenericMethodOrConstructorDecl  // Not modified by 308
>>>>>>      MethodOrFieldDecl               // Modified by 308
>>>>>>      ...
>>>>>>
>>>>>> // Modified by 308
>>>>>> MethodOrFieldDecl:
>>>>>>      UnannType Identifier MethodOrFieldRest
>>>>>>
>>>>>> // Not modified by 308
>>>>>> GenericMethodOrConstructorDecl:
>>>>>>      TypeParameters GenericMethodOrConstructorRest
>>>>>>
>>>>>> GenericMethodOrConstructorRest:
>>>>>>      (Type | void) Identifier MethodDeclaratorRest
>>>>>>      ...
>>>>>>
>>>>>> Type:
>>>>>>      [Annotations] UnannType
>>>>>>
>>>>>> The effect was to allow @B after the type parameter section:
>>>>>>
>>>>>>      public <T> @B Set<T> foo(...) {...}
>>>>>>
>>>>>> and of course @A as a modifier before the type parameter section:
>>>>>>
>>>>>>      public @A <T> Set<T> foo(...) {...}
>>>>>>
>>>>>> Ordinarily, I would change JLS8 to agree with that intent (albeit
> rather
>>>>>> subtle) and with the behavior of both compilers. That is, I would
> regard
>>>>>> this whole topic as a minor spec integration problem.
>>>>>>
>>>>>> Unfortunately, JLS8 cannot be cleanly changed. The problem is the
> ch.8
>>>>>> grammar for MethodHeader, distinct from the old ch.18 grammar. We
> cannot
>>>>>> change MethodHeader to:
>>>>>>
>>>>>> MethodHeader:
>>>>>>      {MethodModifier} [TypeParameters] {Annotation} Result ...
>>>>>>
>>>>>> because, without no type parameters present, any annotations
> immediately
>>>>>> to the left of Result would be ambiguous.
>>>>>>
>>>>>> I am therefore going to leave JLS8 as-is, and ask both compilers to
>>>>>> reject the @B after the type parameter section.
>>>>>>
>>>>>> Alex
>>>
>>>
>>>
>>
>

From alex.buckley at oracle.com  Fri Feb  7 13:59:13 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 07 Feb 2014 13:59:13 -0800
Subject: type closest to a type annotation
In-Reply-To: <OFFCEDA0BC.6699DFAB-ONC1257C78.003BBAED-C1257C78.003E36AA@ch.ibm.com>
References: <OF369F54B9.33A54BF4-ONC1257C77.0055D84A-C1257C77.005D4E8C@ch.ibm.com>
	<52F42197.2040603@oracle.com>
	<OFFCEDA0BC.6699DFAB-ONC1257C78.003BBAED-C1257C78.003E36AA@ch.ibm.com>
Message-ID: <52F55731.7060205@oracle.com>

On 2/7/2014 3:19 AM, Markus Keller wrote:
> Then we better keep "closest". Counterexample:
>
>      @A int[] f;
>
> "The type of the declared entity" here means "the type of variable 'f'",
> which is "int[]", but the type annotation @A applies to "int".
>
> But maybe you could add this sentence at the first occurrence of "closest"
> in 9.7.4?
>
> "The closest type is the lexically first type reference in the declared
> entity's type."

Now I remember why I wrote "closest" :-)

I'll add the text below. I had hoped to appeal to pick out the "first 
lexical occurrence of a type" by building on the tokens classified as 
TypeNames in 6.5.1, but that doesn't include primitive types. I'd rather 
avoid the phrase "type reference" too.

--
In the second and third cases above, the type which is closest to the 
annotation is determined by first taking the type of the declared 
entity, then identifying the first token which itself denotes a type.

NOTE: For example, in the field declaration @Foo public static 
java.lang.String f;, the type which is closest to @Foo is String. In the 
generic method declaration @Foo <T> int[] m() {...}, the type of the 
declared entity is int[], whose first token denoting a type is int, so 
@Foo applies to the type int.
--

Alex