Better encapsulation for AnnotatedType
Werner Dietl
wdietl at gmail.com
Sun Sep 15 00:53:06 PDT 2013
Jon, all,
as you suggested, I encapsulated the typeAnnotations and underlyingType
fields in com.sun.tools.javac.code.Type.AnnotatedType
This actually made the code simpler in a few places.
There is one new failure:
langtools/test/tools/javac/processing/model/type/BasicAnnoTests.java
However, I think the test case is wrong: it uses a "normal" annotation
processor and therefore runs too early. It should be changed to be a
"type annotation processor", i.e. it should run after FLOW.
I suggest we create a subclass/alternative to
JavacTestingAbstractProcessor and use that to test type annotations.
I'm not sure whether this had an effect on javadoc - if so, we should
revisit when the typeAnnotations queue is flushed.
Please review this changeset:
http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/6f595e036db7
If this first step is OK, we can next introduce the TypeMetadata
abstraction.
Regarding SymbolMetadata, I find it a bit strange that the methods that
access SymbolMetadata in Symbol are still called "xxxAnnotations", e.g.
com.sun.tools.javac.code.Symbol.getAnnotations()
Should these also be renamed?
I have one more change that I just pushed:
http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/e1772bcdf768
I changed com.sun.tools.javac.tree.TreeCopier.visitLabeledStatement
to take the copied body instead of the original body.
Charlie Garrett discovered this problem after painful debugging of a
Checker Framework problem that depended on whether a label is present or
not.
I cannot present a simple test case for the error, but the change
doesn't break any existing test cases.
Also note that this was the only "unused variable" warning in
TreeCopier. Warnings are useful.
All comments welcome,
cu, WMD.
More information about the type-annotations-dev
mailing list