JSR 308 RI status and open issues

Werner Dietl wdietl at gmail.com
Thu Nov 15 17:43:20 PST 2012

Let me summarize the status of the different aspects of the
type-annotations branch.

For each big item I provide a link to the issue tracker ticket. For
discussions, I suggest we either start a separate email thread for
that topic or add comments on the issues.
Most other open issues only need double checking and testing to ensure
they are correctly fixed.

- Propagating error counts:
with Jon I'm discussing changes to error count propagation between
rounds. I will change the test cases that I think should be changed
and we will discuss the remaining tests and hopefully find a solution
for them. I want to finish going through all failing tests asap and
will then write up the status.

- Update bytecode representation of type annotations:
The EG provided a new specification on Nov. 7. I've worked through it
and provided feedback. From Alex's comments it sounds like there will
still be more changes. I will start looking into how to implement the
new format, but will wait for the spec to be finalized.
This change is being discussed on the spec-experts mailing list.
This is a big change, as the representation and calculation of
positions changed drastically.

When implementing this change I also want to make sure that
TypeCompounds are only attached to their corresponding symbols.
Currently, an annotation on a parameter is attached to both the
parameter and method symbols, but the position is only updated in one.
This results in TypeCompounds with invalid position. I want to clean
this up and only have one TypeCompound or update both correctly.

- Change to location of annotations on fully-qualified types:
Previously we used "@A java.lang.Object"; this recently was changed to
"java.lang. at A Object".
This needs to be updated in the parser and position calculation. This
change depends on the previous one.

- Integrate repeating annotations and type annotations:
This change was pushed and is awaiting review by Joel/Jon. I
extensively changed when type annotations are processed in
Enter/MemberEnter/Attr and people might see further possible
improvements or problems with these changes.
The position for the container annotation is set in an unfortunate
place - when the annotations are written to the bytecode. A reference
from the contained annotation to the container annotation would help
resolve this. Other suggestions are very welcome.
I unified JCTypeAnnotation into JCAnnotation, which now also has an
Attribute.Compound field "attribute"; this field should be used by
normal annotation handling also.

- Integrate Lambda:
I pulled in jdk8/tl and Lambda features are available, but not
integrated with TAs yet. Maurizio help with disambiguating the
I need to ensure that TAs work in all locations and consider Lambda in
TA position calculations.

- Annotations on catch and resource variables:
Ensure type annotations on catch and resource variables are stored correctly.
Clarify whether catch variables should store the exception table index
or the life range like for a local variable.
Jon will provide feedback on how to implement these storage options.

- Javadoc:
Bhavesh will look into the necessary javadoc changes. I did not hear
what his new schedule is. This should be independent of other changes.

- Reflection and Java language model APIs:
Joel will implement this. I am not sure whether this depends on only
the bytecode representation specification or also on its

- Small open syntax or semantic checks:
x Implement desugaring of anonymous inner classes into a class
declaration (allowing declaration annotations) and an instantiation
(allowing type annotations).
x Syntax and semantic checks for receiver annotations in inner classes.

- Testing:
Last time we discussed a bunch of possible additional testing that
should be done, e.g. of all possible combinations of type annotations
and method return types, method type variables, and modifiers; wild
combinations of arrays, wildcards, and inner types to exercise TA
position calculation; and making sure more obscure syntax is correctly
SQE will work on these tests and add them to the type-annotations repository.
Some of these depend on finalized bytecode representation, but many
more tests should already be possible.

Please do let me know if there is any other feature/component that is
missing or any discrepancy with the specification that you notice.
You can
- add a test case to the repository (in
langtools/test/tools/javac/annotations/typeAnnotations) and/or
- open an issue at http://code.google.com/p/jsr308-langtools/issues/list and/or
- message the mailing list.

All comments welcome!
cu, WMD.


More information about the type-annotations-dev mailing list