[JSR308] Release 0.8 of JSR 308 specification, javac, Checker Framework, and checkers
mahmood at MIT.EDU
Sat Sep 27 16:08:15 EDT 2008
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
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.
---- Changelog for Checker Framework ----
Version 0.8, 27 Sep 2008
Added support for newly specified array syntax
Refactored code for annotating supertypes
Fixed AnnotationBuilder AnnotationMirror string representation
Fixed AnnotatedTypeMirror hashCode
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
Add to-do item: ambiguity in class file format for annotations on
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
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
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
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
More information about the JSR308