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

[Srikanth S Adayapalam]

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.