target_info structure of a method receiver

Joel Borggrén-Franck joel.franck at
Fri Sep 19 11:24:08 UTC 2014

Hi Alex,

Ok, I didn’t realize you used the in scope type parameters (shouldn’t it be type variables to be extra precise?) as type arguments. Two comments inline,

On 19 sep 2014, at 00:00, Alex Buckley <alex.buckley at> wrote:
> On 9/18/2014 1:25 AM, Joel Borggren-Franck wrote:

>> --- 8< ---
>> public class Outer<@B T, @C U> {
>>     class Inner {
>>        Inner(@A Outer<@NotB T, @NotC U> Outer.this) { ... }
>>     }
>> }
>> --- 8< —

>> The type of the receiver parameter Outer<@NotB T, @NotC U> looks like a
>> set of parameterized types to me, not "the type" in singular. Is this
>> problematic?
> The type Outer<@NotB T, @NotC U> is indeed a parameterized type. The quote intends for it to be [a parameterization of] the [generic] class Outer<T,U>. Another plausible type for the receiver parameter is Outer<String,String>. Yet another plausible type is raw Outer. 

Understod. Javac only allows Outer<T, U> as the receiver type (with optimal annotations). Neither Outer<String,String> nor the raw Outer compiles.

>> After this is erased, how should runtime reflection piece together
>> the receiver type? There is no j.l.r.Type subtype that represents a
>> generic class/interface that is not a class/interface declaration. If
>> the receiver type should not be the erased type, is it desirable to
>> represent a set of parameterized types with different type parameter
>> annotations than on the class?
> For your example, I'd expect j.l.r.Constructor#getAnnotatedReceiverType to return a j.l.r.AnnotatedType which exposes @A and is instanceof j.l.r.AnnotatedParameterizedType so you can obtain its annotated type arguments @NotB T and @NotC U. (You happen to have used some in-scope type parameters as the type arguments.)

Unfortunately there is no Signature for the receiver type in the class file for Inner (“LOuter<TT;, TU;>;" doesn’t occur at all in the class file for Inner). If Outer<T, U> (potentially with annotations) is the only possible recover type I can probably work around this in core reflection, if other parameterizations of Outer  should be allowed I need more info in the class file.


More information about the compiler-dev mailing list