type_path of constructors for inner classes

Joel Borggrén-Franck joel.franck at oracle.com
Tue Oct 15 14:20:53 PDT 2013

Hi Alex, Werner,

On 14 okt 2013, at 21:41, Alex Buckley <alex.buckley at oracle.com> wrote:

> Hi Werner,
> On 10/11/2013 10:00 PM, Werner Dietl wrote:
>> On 10/11/2013 10:56 PM, Alex Buckley wrote:
>>> On 10/11/2013 5:13 PM, Werner Dietl wrote:
>>>> Are you saying the correct annotations for the constructor of Inner
>>>> would be:
>>>>      RuntimeVisibleTypeAnnotations:
>>>>        0: #16(#17=I#19): METHOD_RETURN
>>>>        1: #16(#17=I#18): METHOD_RETURN, location=[INNER_TYPE]
>>>>        2: #16(#17=I#19): METHOD_RECEIVER
>>>> That is, the @Annot(1) from the receiver appears again on the return
>>>> and the @Annot(0) appears on the return, with a location.
>>>> Or should we avoid this duplication and only keep 1 and 2, that is the
>>>> two explicit annotations?
>>> Given:
>>>   @Annot(0) Inner(@Annot(1) Test Test.this) {}
> After some more thought, I agree with you. Let's leave the receiver parameter out of this entirely. The type of the newly constructed object has a fully qualified name, but only the final simple name in the qualified name has the annotation from the left of the ctor declaration. That's consistent with the attribute emitted for "Test. at Foo Inner" anywhere else in the body of Inner.

I am assuming you mean "lets not change anything to the encoding of the receiver parameter" by your comment to leave it out of this.

I'm not sure what the consensus is but I think it looks like you both think it is a good idea to add the location to the inner class constructor. As an extra justification, from my standpoint everything gets much simpler if type annotations on Inner has the same location encoding (one level of INNER_TYPE in the example of class Outer { class Inner {}} ) in all cases where it can occur.  While I take your word for it that as a simple name it is unambiguous that really doesn't help when trying to piece this together on the reflective side.


More information about the type-annotations-dev mailing list