RuntimeVisibleTypeAnnotations should be a Code attribute, not a Method attribute

Werner Dietl wdietl at gmail.com
Sun Feb 24 20:13:57 PST 2013


Thanks for the quick reply, Jon! That was all the necessary info.

I pushed this change:

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

Note how now an annotation on a return type and on a local variable
looks like this in javap:

    Code:
      stack=1, locals=1, args_size=0
         0: aconst_null
         1: astore_0
         2: invokedynamic #2,  0              // InvokeDynamic
#0:lambda$:()Ljava/lang/Runnable;
         7: areturn
      LineNumberTable:
        line 155: 0
        line 156: 2
      RuntimeInvisibleTypeAnnotations:
        0: #16(): LOCAL_VARIABLE, {start_pc=2, length=6, index=0}
    RuntimeInvisibleTypeAnnotations:
      0: #23(): METHOD_RETURN


That is, there are two separate Attribute sections, first for the
Code, then for the Method.
It would be great if somebody could verify I do this according to the
specification.

Steve/SQE, I updated the referenceinfos tests, in particular:

langtools/test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java

I didn't update all the javac/classfile and javap tests for this.
In particular:

langtools/test/tools/javap/typeAnnotations/NewArray.java

would benefit from reusing logic from

langtools/test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java

That later class needs to be adapted to also look in Code attributes.
Could you make a patch for type-annotations that I can integrate?

Thanks,
cu, WMD.


On Sun, Feb 24, 2013 at 6:48 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
> On 02/24/2013 06:17 PM, Werner Dietl wrote:
>>
>> Jon, all,
>>
>> Eric Bruneton mentions on the spec-comments list that
>> RuntimeVisibleTypeAnnotations should be a Code attribute, not a Method
>> attribute:
>>
>>
>> http://mail.openjdk.java.net/pipermail/type-annotations-spec-comments/2013-February/000021.html
>>
>> How can I very whether this is the case or not?
>>
>> I looked at:
>>
>> com.sun.tools.classfile.ClassWriter.writeMethod(Method)
>> com.sun.tools.classfile.Code_attribute.attributes
>> com.sun.tools.classfile.RuntimeInvisibleTypeAnnotations_attribute
>>
>> but I don't see where a decision between Code and Method is made...
>> both have attributes and I don't see where
>> RuntimeInvisibleTypeAnnotations_attribute is put in one or the other.
>> Before I spend more time in debugging, do you know where this happens?
>>
>> Thanks,
>> cu, WMD.
>>
>
> com.sun.tools.classfile is a simple library underpinning javap, and does not
> enforce any validity constraints.
>
> The decision where to put annotations attributes is made in javac.
> Start in Names.java to find RuntimeVisibleTypeAnnotations (c. line 280)
> then track from there to javac.jvm.ClassWriter in writeTypeAnnotations,
> then to writeMemberAttrs (line 635).
>
> -- Jon
>



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


More information about the type-annotations-dev mailing list