Better encapsulation for AnnotatedType
jonathan.gibbons at oracle.com
Mon Sep 16 15:21:27 PDT 2013
Wow, great. I'll take a look.
On 09/15/2013 12:53 AM, Werner Dietl wrote:
> 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:
> 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:
> If this first step is OK, we can next introduce the TypeMetadata
> Regarding SymbolMetadata, I find it a bit strange that the methods that
> access SymbolMetadata in Symbol are still called "xxxAnnotations", e.g.
> Should these also be renamed?
> I have one more change that I just pushed:
> 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
> 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