[JSR308] Release 0.8 of JSR 308 specification, javac, Checker Framework, and checkers

[Mahmood Ali]

We have released version 0.8 of the JSR 308 specification and  
implementation and of the Checker Framework.  You can always review  
the latest version of the specification at: http://groups.csail.mit.edu/pag/jsr308/specification/java-annotation-design.html 
  ; and download the latest version of these tools at:http://groups.csail.mit.edu/pag/jsr308/ 
  .

The JSR 308 implementation is a backward-compatible extension to  
javac. The Checker Framework makes it easy to write a tool that finds  
or prevents errors; the tool is expressed as a type-checker for a  
pluggable type system.  The Checker Framework distribution includes  
sample checkers.

This release includes support for the finalized array syntax  
convention in the specification, some bug fixes and API re-factoring.

The changlogs of the specification and the implementations appear below.

     - Mahmood

---- Changelog for Checker Framework ----
Version 0.8, 27 Sep 2008

Framework
   Added support for newly specified array syntax
   Refactored code for annotating supertypes
   Fixed AnnotationBuilder AnnotationMirror string representation
   Fixed AnnotatedTypeMirror hashCode

Manual
   Reorganized 'Annotating Libraries' section

---- Changelog for JSR 308 specification  ----
Changes to normative section:

   In class file format, add missing fields from attributes for method  
parameter generic types and method type arguments. Also cross- 
reference between the table of target_type and sections explaining the  
reference_info definition.
   Add to-do item: ambiguity in class file format for annotations on  
inner classes.
   Provide a better citation for the JDK 1.5 class file format.
   Restructure introduction to section 4 (class file format), to  
separate the summary of the current class file from the summary of the  
changes. Clarify other parts of section 4 as well. This doesn't change  
the specification, just improves the writing.

Changes to non-normative section:
   Separate reflection section into things that need to be done, and  
things that need not be done — it's mostly the latter!. Also, delete  
old reflection proposal an replace it by a simpler yet more expressive  
one. (Both the old and the new are high-level and remain to be fleshed  
out.)
   Many writing improvements and clarifications, including discussions  
of duplicate annotations, subclassing annotations, and annotations as  
arguments to annotations, disambiguating type and declaration  
annotations, annotations on new, and receivers (including an explicit  
definition of the term “receiver”). Also expand several examples to  
show actual declarations instead of just explaining them in the text.
   More extensive explanation of duplication issues with subclassing  
annotations. Conclusion: this should be deferred to the specific  
annotation processor, since there is no one-size-fits-all solution.  
Also, suggest that annotations that can be duplicated should be  
explicitly so marked.
   Undo one level of sectioning in appendix D (about possible other  
annotation changes). Emphasize again that the specification is not set  
in stone. Add another possible (but currently out of scope) extension  
to annotations: the @ValueMember proposal for the  
SingleElementAnnotation grammar rule.
   Add quotations from the (rather obscure) JSR 175 Design FAQ,  
explaining the rationale for several JSR 175 annotation design  
decisions:
     o Why is it illegal [to] annotate a single element repeatedly  
with the same annotation type?
     o Why can't you annotate arbitrary program elements such as  
blocks and individual statements?
     o Why don't you support annotation subtyping (where one  
annotation type
     o Why is it illegal for an annotation type to contain an element  
of the same type?

Changes to introduction:
   Reference the FAQ.
   Explain the term “JSR” earlier in the document.

Changes to FAQ:
   Emphasize backward compatibility.
   New question on how to write a checker.
   New question on why the Type Annotations Specification doesn't  
define annotation types.
   New question on how to determine the annotation on an object.

---- Changelog for JSR 308 implementation ----
Version 0.8, 27 Sep 2008

No changes