[jsr-308-eg] Fw: Syntax for type annotations on fully-qualified types

[Alex Buckley]

Hi Srikanth,

I respect your concern that it's a bad idea to separate a) the syntactic 
location of an annotation from b) the semantic entity to which it 
applies. As you say, for array types we kept an annotation "close" to 
the exact type being annotated. In fact, I think your proposal works 
especially well for array types, because this:

   p1.p2. at Foo C @Bar []  x,y;

is more readable to my eye than:

   @Foo p1.p2.C @Bar []  x,y;

The JSR 308 spec currently notes that "For a nested type, the type 
annotation appears before the type's simple name." Your proposal allows 
"For a nested type" to be removed. On balance, I can agree with your 
proposal.

(I still don't think package names will be annotated anytime soon :-) )

Alex

On 10/22/2012 4:37 AM, Srikanth S Adayapalam wrote:
> Hello EG,
>
> 	We have come a long way in the Eclipse Compiler & IDE implementation
> of JSR308 and
> with a much better appreciation of the issues involved in implementation,
> would like to revive
> this topic which came up for discussion several months ago:
>
>> From: Michael Ernst <mernst at cs.washington.edu>
>> To: jsr-308-eg <jsr-308-eg at jcp.org>
>> Date: 31-01-12 04:42 AM
>> Subject: [jsr-308-eg] Fw: Syntax for type annotations on fully-qualified
> types
>> Sent by: jsr-308-eg-bounces at jcp.org
>
> [...]
>
>> I'd like to get your feedback on a recent proposal that the syntax of a
>> type annotation on a fully-qualified type should be
>>    java.lang. @A Object
>> rather than
>>    @A java.lang.Object
>> The specification currently says the latter, but each has its benefits.
>
> [...]
>
>> Arguments for the change to java.lang. at A Object include:
>>   * more uniform with respect to nested classes
>>   * easier for people to interpret, and possibly easier to implement
>>   * allows future extensions such as annotations on packages
>>
>> Arguments for the current @A java.lang.Object include:
>>   * more aesthetically pleasing, at least to some people; does not break
> up
>>     the unit "java.lang.Object"; unlike the "OuterClass" type prefix, the
>>     "java.lang." package prefix feels like a part of the type
>>   * the change primarily improves the syntax for annotations on
> fully-qualified
>>     nested types.  Maybe those do not come up that often in practice, and
>>     maybe the change would make the syntax worse in the common case.
>>
>> Thoughts?
>
> And Doug Lea responded with:
>
>> From: Doug Lea <dl at cs.oswego.edu>
>> To: jsr-308-eg at jcp.org
>> Date: 31-01-12 05:33 AM
>> Subject: Re: [jsr-308-eg] Fw: Syntax for type annotations on
> fully-qualified types
>> Sent by: jsr-308-eg-bounces at jcp.org
>
> [...]
>
>>> Arguments for the change to java.lang. at A Object include:
>>>    * more uniform with respect to nested classes
>>>    * easier for people to interpret, and possibly easier to implement
>>>    * allows future extensions such as annotations on packages
>>
>> This last point seems like the best reason to change syntax.
>> Although I suppose some paren rules could be introduced
>> to cover (@A java).lang.Object and the like?
>
> [...]
>
>> Also,  the current scheme seems more in keeping with rules for
>> qualifiers and cast expressions across dots for method calls.
>> As in:
>>     (long)aString.length()
>> not
>>     aString.(long)length();
>
> And Alex Buckley further responded with:
>
>> From: Alex Buckley <alex.buckley at oracle.com>
>> To: jsr-308-eg at jcp.org
>> Date: 31-01-12 07:56 AM
>> Subject: Re: [jsr-308-eg] Fw: Syntax for type annotations on
> fully-qualified types
>> Sent by: jsr-308-eg-bounces at jcp.org
>>
>> Hi Mike,
>>
>> In my view, the uniformity of
>>
>>     p1.p2. at A C1
>>
>> with
>>
>>     p1.p2.C1. at A C2
>>
>> is not worth much because I don't think nested type names are usually
>> qualified in the first place.
>> That is, I expect most utterances of a nested type's name are made in
>> either the scope of the nested type's declaration or the scope of an
>> import declaration, so use a simple type name. We offer a mechanism for
>> annotating a nested type name should it be qualified (C1. at A C2 or
>> p1.p2.C1. at A C2) but it's somewhat secondary in everyday use.
>>
>> I think it's quite reasonable to say that an annotation before a
>> qualified type name applies to the top-level type named therein
>> (p1.p2.C1) and not to nested types of any depth (i.e. not to the type
>> p1.p2.C1.C2 or p1.p2.C1.C2.C3 or p1.p2.C1.C2.C3.C4, etc).
>>
>> Let's talk about annotations on packages:
>>
>> - First, is Java SE going to support annotating a specific use of a
>> package name (as opposed to a package declaration) in the next 10 years?
>> Probably not.
>>
>> - Second, even if a need was identified, I would observe that any
>> proposition made about a package name at a use-site could be rolled up
>> into a proposition on a top-level type name at the same use-site, i.e.
>> rather than "@A java.lang. at B Object" to represent the A-ness of the
>> java.lang package and the B-ness of its Object type, write "@AandB
>> java.lang.Object" where the annotation applies to the top-level type and
>> let the checker figure out that the annotation proposes something about
>> the package too.
>>
>> (Yes, this paragraph could be applied against nested types in general,
>> or against the ability to annotate nested type names distinctly from
>> top-level type names. But package names are already second-order in
>> mainline code, so worrying about how to annotate them in a potential
>> future is third-order at best.)
>>
>> - Third, annotations on expressions/statements (more plausible than on
>> package names) will face the problem of grouping alluded to by Doug -
>> (@A java).lang.Object - but 1000 times worse. So let's cross that bridge
>> when we come to it, and perhaps apply it to package names if the need is
>> there.
>>
>> Bottom line, I'm not too concerned about qualified nested type names or
>> about annotating package names, so I think the current 308 spec is fine.
>
> In the current scheme of things, the component of the qualified name that
> gets
> annotated cannot be determined purely by parsing the program and symbol and
> type resolution is mandatory to ascertain that.
>
> Unlike other programming languages, Java has always strived to be precise
> and unambiguous. It would be better to keep grammatical concepts in the
> grammar and not defer them to a second, context-dependent compiler phase.
> Moreover, this is the only place where annotations don't appear directly
> in front of the type. The same arguments as given for annotations on
> array types (2.2.1) also apply here.
>
> Furthermore, the current spec precludes further language enhancements.
> At one time, we may want to add annotations to package references, and
> this is not easily possible any more if "@Annot java.util.List" cannot
> mean that "java" or "java.util" is annotated.
>
> Of course, this last point has been already discussed and (a) a plausible
> work around has already been identified (@Annot java) and (b) is tagged
> as an unlikely scenario in the next 10 years - and argued as let us cross
> the bridge when we get to it.
>
> Looking back at the arguments, I see only one valid argument (the others
> are for why we can live with the present syntax as opposed to is strengths)
> for retaining the present syntax : that it could be "more aesthetically
> pleasing, at least to some people; does not break up the unit
> "java.lang.Object"
>
> However if we agree that in real terms this is not an issue as we expect
> imports to be in place that argument also loses potency.
>
> The particular implementation issue we are facing is that, there are
> various
> AST API clients of Eclipse that could ask for an AST without symbol and
> type resolution - i.e the pure output of the parser without further
> processing/decorations. We would prefer to be able to discover the
> component of the qualified name that is annotated without symbol/type
> resolution and this is not possible today with the present syntax.
>
> This has the potential to make client code greatly complicated in that
> they need to be prepared to expect to annotations on non-type nodes and
> do the "right thing."
>
> In the java.util. at Marker Object scheme, this problems goes away completely
> as the presence of type annotations signals that the following component
> is a type and only those clients that need to something with the type
> nodes need to react.
>
> Comments ?
>
> Srikanth.
>