This table summarizes what known open issues are, both in the specification and the RI, and points to the discussions on the mailing lists.
| Issue | Next responsible | Email thread |
|---|---|---|
| Desugaring of anonymous classes | EG, Steve | Finalize the discussion: Ensure the implementation is in conformance. |
| Receiver parameter name | EG, wmdietl | Receiver parameter name checks should not be based on Strings, but on semantics: The EG needs to finalize the spec on what receiver parameter names are legal: |
| Receiver parameter API | wmdietl | Provide nicer integration of receiver parameters: |
| Method/Constructor distinction | EG | A proposed change needs to be decided: http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-April/000106.html |
| Interaction between Target and qualified names | wmdietl | Ensure recent discussion is implemented: |
| JLS Creator production | EG, Mike | A production needs an update in the spec: |
| Review multi-catch implementation | Jon, Vicente | http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-April/000829.html |
| Cleanup test cases | Joel, Steve | http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-April/000893.html http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-April/000867.html I looked into the test code for 8013965 and found it to be a duplicate of 8008762. I closed 8013065 as a duplicate. |
| Address remaining javadoc issues (type annos on type parameters) | Jon, Bhavesh | See @ignored test cases in javadoc type anno tests |
wmdietl will also keep the Google Code issue tracker up-to-date:
https://code.google.com/p/jsr308-langtools/issues/list
Aspects that should be tested more thoroughly by SQE: