[JSR308] JSR 308 documents and tools released

[Neal Gafter]

Compared to my previous comments on the spec and implementation, I don't see
much improvement. This work does not yet appear to be moving closer to
something that I can imagine Sun adopting into the Java Language
Specification and compiler.  To review:

   - The spec is not a spec. Although the proposal states "This document
   specifies the *syntax* of extended Java annotations, but it makes no
   commitment as to their *semantics*." it
      - fails to specify the syntax (there is no BNF anywhere in the
      document, only examples), and
      - makes commitments based on semantics (for example, the final
      paragraph of section 3.3, which justifies basing the syntactic
      design on the semantics of currently-known use cases)
   - Although the proposal states "We propose an extension to Java's
   annotation system
[Bra04a<http://pag.csail.mit.edu/jsr308/java-annotation-design.html#JSR175>]
   that permits annotations to appear on any use of a type.", the proposal does
   not address any of the six contexts that I identified by email to this list
   on February 24 2007 at 11:28pm. A straightforward extension of the proposal
   to handle the six contexts would appear to result in syntactic ambiguities
   (but without a specification one cannot be sure)
   - The implementation techniques are inconsistent with javac's design
   and inappropriate for the long-term maintenance of javac:
      - In com.sun.tools.ClassTree, parallel lists are used for
      "implements" annotations, rather than properly structured ASTs
that include
      the annotations in the tree for the annotated type.
      - Similarly, annotations on uses of types appear in the
      enclosing structure rather than in the tree representing the
type everywhere
      else, resulting in a significant increase in complexity of the tree
      definitions and code where types appear.
      - AnnotationTarget and its evil cousin TargetType appear to be
      used to support code generation, but the data structures, code
and logic are
      spread throughout the compiler.
      - The attribution phase improperly modifies the ASTs and
      symbols. For example, annotations are copied from within the body of a
      method to the method itself in support of code generation. (Data
structures
      and transformations required for code generation should be done
during code
      generation)
   - The parsing strategy is overly convoluted, with the code attempting
      to carry around types and type modifiers separately. The
following code in
      Parser is typical of the sort of hard-to-find bugs this produces:
         - t = argumentsOpt(typeArgsMods.toList(), typeArgs,
         typeArgumentsOpt(t, typeArgsMods));
      - Annotation processing seems to have been revised to require an
   additional complete compilation pass (see compile0 in JavaCompiler)
   - The parser accepts absurd combinations of tokens, in part because of
   the difficulty of correctly implementing the selected design strategy. The
   following are treated as syntactically and semantically valid statements
   (assuming an appropriate x and f and X are defined, but foo undefined):
   - x = @foo x;
      - int y = @foo f();
      - int y[final];
      - int y = (final x);
      - int y = x[final 3];
      - Object x = new X<final Integer>();
      - The phase ordering for processing type annotations looks
   dangerous (i.e. not lazy enough).

Regards,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20070706/2389ade1/attachment.html