Constructor receiver annotations

[Alex Buckley]

On 11/26/2013 2:08 PM, Werner Dietl wrote:
> For the second constructor:
>
>    Outer$Middle$Inner(Outer$Middle, java.lang.Object);
>      descriptor: (LOuter$Middle;Ljava/lang/Object;)V
>      flags:
>      Code:
>      ...
>      RuntimeInvisibleTypeAnnotations:
>        0: #17(): METHOD_RETURN, location=[INNER_TYPE, INNER_TYPE]
>        1: #18(): METHOD_RECEIVER, location=[INNER_TYPE]
>        2: #19(): METHOD_RECEIVER
>        3: #15(): METHOD_FORMAL_PARAMETER, param_index=0
>
> Again, the param_index should be 1.

I agree.

> However, the annotations that apply to the METHOD_RECEIVER actually
> also apply to param_index 0 - because in cases like this, the receiver
> parameter is explicit.
> What should the bytecode look like?
> Should the annotations be duplicated on param_index 0?
>
>      RuntimeInvisibleTypeAnnotations:
>        0: #17(): METHOD_RETURN, location=[INNER_TYPE, INNER_TYPE]
>        1: #18(): METHOD_RECEIVER, location=[INNER_TYPE]
>        2: #19(): METHOD_RECEIVER
>        3: #18(): METHOD_FORMAL_PARAMETER, param_index=0, location=[INNER_TYPE]
>        4: #19(): METHOD_FORMAL_PARAMETER, param_index=0
>        5: #15(): METHOD_FORMAL_PARAMETER, param_index=1
>
> Or should they only be present on param_index 0?
> What does reflection return in this case?

Per JLS 8.4.1 as updated by JSR 308, the receiver parameter is not a 
formal parameter. @TA and @TB on the receiver parameter should not be 
duplicated as METHOD_FORMAL_PARAMETER type_annotation structures (4 and 5).

> What should happen if the bytecode is inconsistent about this, e.g.
> the METHOD_RECEIVER contains some annotations and param_index 0
> contains different annotations?

It is theoretically possible to write an inner class constructor in Java 
without a receiver parameter and obtain just a METHOD_FORMAL_PARAMETER 
structure with param_index=0. This obscure situation would occur if the 
inner class was local, and if the compiler chose not to represent the 
immediately enclosing instance via an <init> parameter. In such a class 
file from a Java compiler, it would make no sense to have a 
METHOD_RECEIVER structure. But in non-Java class files, I don't see it 
as a problem that the 0th formal parameter is logically annotated as 
both METHOD_RECEIVER and METHOD_FORMAL_PARAMETER.

Alex