ElementType.TYPE_USE for a type parameter

[Werner Dietl]

Hi Steve, Alex,

I changed the checks to allow TYPE_USE annotations on type parameter
declarations and expanded the corresponding test case. See:

http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/bf0c0c96388b

One test case did expect this error, so I assume this was a spec
change that hadn't been implemented yet.
Please do let me know whether this now behaves as expected.

cu, WMD.

On Mon, Dec 10, 2012 at 1:43 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> Hi Steve,
>
> The source you wrote below is completely valid.
>
> @Uv on the class declaration of Test1 correctly produces a
> RuntimeVisibleAnnotations attribute on the class.
>
> @Uv on the type parameter declaration of g should produce a
> RuntimeVisibleTypeAnnotations attribute on the method.
>
> (A type parameter annotation on a generic type or method is technically on a
> declaration, and so "ought" to get RuntimeVisibleAnnotations, but this is
> impractical, so in fact it gets RuntimeVisibleTypeAnnotations.)
>
> There must a bug in the treatment of TYPE_USE annotations on type
> parameters. It fails in a generic class declaration too: "class Test1<@Uv X>
> ...". But @Uv does work as a pure use-site annotation: "class Test1<X
> extends @Uv String> { @Uv int f; }"
>
> Summary: a TYPE_USE annotation works in TYPE and "use" locations, but not
> TYPE_PARAMETER locations.
>
> Alex
>
> On 12/10/2012 1:11 PM, Steve Sides wrote:
>>
>> Hi,
>>
>> I starting writing some tests mixing a combination of ElementType
>> targets and ran into some questions.
>> Section 2.3 says,
>>
>> "A type annotation (one meta-annotated with
>> @Target(ElementType.TYPE_USE)) is permitted to be written anywhere
>> @Target(ElementType.TYPE) or @Target(ElementType.TYPE_PARAMETER) would
>> permit — that is, on a class, interface, or enum declaration, or on a
>> type parameter declaration."
>>
>> Should this mean that an annotations such as
>> @Retention(RUNTIME)
>> @Target(ElementType.TYPE_USE)
>> @interface Uv {}
>>
>> should be able to be used as
>>
>> @Uv public class Test1 {
>> <@Uv T> String g(T t) { return null; }
>> }
>>
>> In the case of the first usage, it appears as RuntimeVisibleAnnotations
>> and not RuntimeVisibleTypeAnnotations.
>> The second is not accepted by the compiler.
>>
>> Are both these current behaviors expected? Am I reading that correctly?
>>
>> thanks,
>> steve
>>
>>
>>> which made the AST nicer, because we no longer need the onRightType
>>> hackery.
>>> I renamed the constants and updated the tests in
>>>
>>> langtools/test/tools/javac/annotations/typeAnnotations/referenceinfos/
>>>
>>> to the new location format. It's a pain to write these byte arrays by
>>> hand, but I didn't see a quick way to update the testing
>>> infrastructure.
>>>
>>> Please have a look at the tests and the code and let me know whether
>>> you see any problems.
>>>
>>> I will next:
>>> - fix inner type numbering
>>> - fix JavaDoc/Symbol issue
>>> - look at exception and lambda storage (I added constants and some
>>> groundwork; for lambda i really need a spec to know what has to be
>>> stored.)
>>> - the few small other things from previous mail
>>>
>>> cu, WMD.
>>>
>>>
>>> On Wed, Dec 5, 2012 at 6:03 PM, Jonathan Gibbons
>>> <jonathan.gibbons at oracle.com>  wrote:
>>>>
>>>> On 12/03/2012 01:15 AM, Werner Dietl wrote:
>>>>>
>>>>> Please find a patch against the type-annotations/langtools repository
>>>>> attached (I just pushed a recent merge with tl).
>>>>> I implemented many of the recently discussed bytecode changes: reorder
>>>>> elements, remove _COMPONENT TargetTypes, and introduce TypePathEntry.
>>>>> It's not quite done yet: I still need to separate numbering of type
>>>>> arguments and arrays/inner types, renumber inner types, and adapt the
>>>>> referenceinfo test cases (which will be a big pain and I would prefer
>>>>> doing this only once).
>>>>>
>>>>> I would appreciate feedback on the changes to class
>>>>> com.sun.tools.javac.code.TypeAnnotationPosition, in particular how I
>>>>> added TypePathEntry, TPEKind, and the new location field.
>>>>> The whole com.sun.tools.javac package hierarchy compiles; packages
>>>>> classfile and javap currently won't compile, as they depend on code
>>>>> duplicated from TypeAnnotationPosition and I only want to copy that
>>>>> code over once. The uses are however mostly adapted already.
>>>>>
>>>>> All comments very welcome!
>>>>> cu, WMD.
>>>>>
>>>> Generally, code looks good, except for the //TODO's.
>>>>
>>>> -- Jon
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>



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