Annotations on Type

[Werner Dietl]

Jon,

thanks for that info.
Will the type-annotations repositories continue to exist?
Once the jdk9 repos are created, we could continue to use
type-annotations to test type-annotation fixes.

cu, WMD.



On Thu, Dec 5, 2013 at 6:44 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
> Werner,
>
> The time has passed for small fixes in JDK 8.   We are planning to fix a
> bunch of type-anno stuff when 9 opens, and hopefully backport the fixes into
> an early 8 update.   We can look at your additional fixes at the same time.
>
> -- Jon
>
>
>
> On 12/05/2013 02:08 PM, Werner Dietl wrote:
>>
>> Hi all,
>>
>> I just noticed that the following test is @ignored:
>>
>> test/tools/javac/processing/model/type/BasicAnnoTests.java
>>
>> The test doesn't have a valid bug ID, so I couldn't check whether
>> anyone is working on it.
>> I found this mailing list discussion, which I think was the start for
>> this test case:
>>
>>
>> http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-January/000532.html
>>
>> In the type-annotations repository, I've added more test cases that
>> illustrate another aspect of this issue.
>>
>> If you have a generic type like "List<@TA String>" the type annotation
>> @TA is correctly put into the String tree.type field (in
>> com.sun.tools.javac.comp.Attr.annotateType(...).new Worker()
>> {...}.run()), however, this happens after the type for List is
>> generated.
>> The List tree only has type "List<String>" instead of "List<@TA String>".
>> The later modification of the type of String obviously doesn't modify
>> the type argument list for the "List" type.
>> com.sun.tools.javac.comp.Attr.visitAnnotatedType(JCAnnotatedType) only
>> takes the un-annotated type.
>> When com.sun.tools.javac.comp.Attr.visitTypeApply(JCTypeApply) creates
>> the list of actuals, it stores these un-annotated types. Later updates
>> to the type argument Trees are then not reflected here.
>>
>> In a previous iteration, we created an AnnotatedType with empty
>> annotations and later filled in the actual annotations. This ensured
>> that all locations that referenced the AnnotatedType were updated, but
>> had other drawbacks.
>>
>> Is somebody working on fixing this test case?
>> Any ideas for how we can fix this?
>>
>> I pushed the extended test case to the type-annotations repository:
>>
>>
>> http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/882808d3b51f
>>
>> I also performed a few cleanups:
>>
>> - get rid of all "unused import" warnings in langtools javax packages:
>>
>> http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/f8b150f1e339
>>
>> - typo fix:
>>
>> http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/113d21b7ced6
>>
>> - improve an error message:
>>
>> http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/7e1e8c568a26
>>
>> - don't build an error String for a simple null check:
>>
>> http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/bbf852ffad28
>>
>> - don't create unused local variable:
>>
>> http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/f189794ce07a
>>
>> All feedback and reviews for pushing to TL welcome!
>>
>> Cheers,
>> cu, WMD.
>>
>



-- 
http://www.google.com/profiles/wdietl