Constraining type annotations to occur just before type
mernst at cs.washington.edu
Sat Mar 30 11:34:57 PDT 2013
To follow up, I am convinced by the analogy to other code that is in bad
style (but isn't forbidden by the compiler). That's in addition to the
issues I brought up in my previous message. So, we'll keep the spec as it
is. But, this would be a good thing for an IDE or code quality tool to
I've added the advice about order of annotations (type annotations come
last, immediately before the type name) to the JSR 308 specification.
> Subject: Re: Constraining type annotations to occur just before type
> From: Alex Buckley <alex.buckley at oracle.com>
> To: type-annotations-spec-experts at openjdk.java.net
> Date: Thu, 21 Mar 2013 12:51:31 -0700
> On 3/21/2013 10:21 AM, Michael Ernst wrote:
> > I agree entirely that it is terrible style to mix type annotations and
> > declaration annotations (the declaration annotations should always come
> > first) and that it is terrible style to mix type annotations with modifiers
> > (the modifiers should come first). So, Alex's suggestion to change the
> > advice is definitely good. Alex, can you make that change? It's outside
> > the scope of the JSR 308 specification.
> Since type annotations are the reason to change the advice about modifier
> order, the 308 spec should have a note giving the preferred layout of
> declaration annotations v. type annotations. I will then incorporate it
> into JLS sections which use modifiers.
> > I consider it an infelicity in the Java grammar that (declaration)
> > annotations are considered modifiers and are lumped in with them, and even
> > worse that type annotations get lumped in with declaration annotations.
> > Logically, there are types and modifiers, and a type consists of optional
> > type annotations followed by a Java type. This is how people should write
> > them.
> Carefully distinguishing declaration annotations from type annotations
> would be the heart of the new note :-)
> > Now, the question is whether or not the Java language should strictly
> > enforce this practice.
> > I'm sympathetic to this change -- probably my position is between
> > Srikanth's and Alex's. I see the benefit of preventing confusing code
> > rather than just advising programmers not to write it in the first place
> > and then giving them rope to hang themselves.
> I understand, but there are infinite ways to writing confusing code in
> Java, and none of them get their own compile-time error. Even potentially
> unsafe use of raw types - which can lead to unpredictable program
> termination! - only gets a compile-time warning. I think people are
> over-rotating towards the IDE context, where informative messages and
> warnings abound, rather than focusing on hard-edged rules of the language.
> > Incidentally, the Annotation File Utilities (AFU) grammar has these
> > productions:
> > Elsewhere, the AFU grammar always uses the decl-annotation or
> > type-annotation non-terminal, rather than just using the "annotation"
> > non-terminal. The AFU grammar would accept exactly the same annotation
> > files if it did not contain the decl-annotation and type-annotation
> > non-terminals, but those clarify the meaning.
> > We could imagine doing a similar thing with the JLS grammar, though the
> > required changes would be more extensive. Modifiers would include
> > declaration annotations but not type annotations, which would be rolled
> > into types. I suspect that the reason I didn't do this in the first place
> > was because I was trying to make the changes to the JLS grammar as minimal
> > as possible to clarify what was actually changing. We've since moved away
> > from that position (and even if we hadn't, what's good for a diff isn't
> > necessarily good for a final version).
> As Jon implied in , the grammar would have to be relaxed (use only the
> Annotation non-terminal) because parsers cannot in general do the semantic
> analysis required to distinguish decl. from type annotations. It would have
> to be a higher-level complaint - either a standard compile-time error or a
> compiler-specific lint warning - if a decl. annotation is used where a type
> annotation is required, and vice-versa.
> However, we cannot say that decl. annotations must come before traditional
> modifiers (private/public/static/final etc) because it has been legal since
> Java SE 5.0 to mix them up. The only rule which could possibly be added is
> "type annotations are not modifiers, and occur after all modifiers (which
> include declaration annotations)". I personally remain to be convinced that
> this rule is necessary.
More information about the type-annotations-spec-experts