ElementType.TYPE_USE for a type parameter

[Werner Dietl]

Hi Alex,

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

I pushed a changed bytecode representation yesterday, but there are
still some open issues with counting inner types.
Do you have a cut-off date for what will get into this next binary build?

Also, some of my comments on the Nov. 7th spec were about the bytecode
representation and spec and impl might vary there.

cu, WMD.


> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>



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