[type-annos-observers] annotations on type uses in throws and catch clauses
Michael Ernst
mernst at cs.washington.edu
Thu Apr 4 21:02:07 PDT 2013
Srikanth-
Thanks for forwarding these comments! You've identified a flaw in the JLS
grammar, which seeped through into the JSR 308 grammar. I've made changes
to the specification in response.
> I would assume the @NonCritical in the modifiers list only
> applies to the first type of the union:
>
> catch (final @NonCritical AccountException | @Critical AccessException
> ex)
>
> Note that the classfile format currently mixes the annotations of all union
> types together into one EXCEPTION_PARAMETER entry for the catch variable.
> ... But the spec doesn't say a word about the union type case. There's
> just the table in 3.2 and section 3.3.8, from which we have to assume that
> the annotations from all union types are collapsed into the same
> EXCEPTION_PARAMETER target.
>
> If I can put different annotations on different
> union type alternatives, then I would expect them to be treated separately.
> Currently, the compilation cuts the connection from an EXCEPTION_PARAMETER
> annotation to its type.
The easy answer to your comment is that your proposed syntax for an
exception parameter declaration
catch (final @NonCritical AccountException | @Critical AccessException ex)
is not legal according to the current JSR 308 specification. A programmer
can currently only write an annotation at the beginning of the exception
parameter declaration.
You might ask, why *isn't* it possible to write
catch (final @NonCritical AccountException | @Critical AccessException ex)
? The answer is that it should be possible! This is a bug in the JSR 308
specification.
As background, the JLS grammar is sloppy about whether a particular
construct is a type use or something else. The JSR 308 spec changes the
JLS grammar to clarify this issue, but this is a case that I missed. I'm
amazed that it took until now for anyone to notice this.
I have changed the JSR 308 grammar to rename the non-terminals that are
used in throws and catch clauses. The throws and catch grammar rules now
use QualifiedTypeList and QualifiedType (which can be annotated), rather
than QualifiedIdentifierList and Identifier which cannot. Note that type
parameters and arrays are forbidden in such locations.
Also note that there is no way to write a single annotation that applies to
all the types in the multi-catch. This may cause a bit of duplication, in
that a programmer may need to write a given annotation on all the clauses
of a multi-catch. However, being able to annotate each disjunct
individually is more expressive.
I added some explanatory text in section 3.3.8 that the source code's
correspondence between union type alternatives and annotations must be
maintained in the classfile. This is obvious, but as you point out, it is
worth stating explicitly to avoid confusion. It is already possible to
write a legal classfile in which there are two entries in the exception
table, with different annotations. That shows how a compiler can compile
such code.
I also clarified that the JSR 308 spec does not specify the semantics of
any annotation type, though of course it does specify both source and
classfile syntax and the mapping between them.
I am attaching the latest version of the specification, with my changes.
Let me know if I made any late-night-editing goofs.
Thanks again for the very useful comments that are helping to smooth out
rough corners in the specification! I appreciate it, and please keep them
coming.
-Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: design.pdf
Type: application/pdf
Size: 208973 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/attachments/20130404/66ce0ea9/design-0001.pdf
More information about the type-annotations-spec-observers
mailing list