ElementType.TYPE_USE for a type parameter

[Alex Buckley]

Hi Werner,

Thanks for the quick changeset! The policy of allowing TYPE_USE 
annotations at TYPE and TYPE_PARAMETER declaration sites (as well as use 
sites) is pretty clear in the spec. I also assume it was just an 
oversight in javac.

FYI we will be pushing new binaries for the type-annotations forest to 
jdk8.java.net/type-annotations very soon. Maybe with this changeset.

Alex

On 12/10/2012 3:08 PM, Werner Dietl wrote:
> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
>