target_info structure of a method receiver

[Alex Buckley]

On 9/19/2014 4:24 AM, Joel Borggrén-Franck wrote:
> 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.

I used them? You mean, you used them.

(Yes, technically, the type arguments of the parameterized type
Outer<...,...> are type variables in your example ... namely, type
variables declared as the type parameters of the generic class
Outer<T,U>. I find that "type variables" is often used when people don't
realize the difference between a type argument and a type parameter, so
I avoid it most of the time.)

> On 19 sep 2014, at 00:00, Alex Buckley <alex.buckley at oracle.com>
> wrote:
> Understod. Javac only allows Outer<T, U> as the receiver type (with
> optimal annotations). Neither Outer<String,String> nor the raw Outer
> compiles.

I realized after sending my mail that Outer<String,String> and raw Outer
were not good examples for this situation. It's right that javac rejects 
lazy uses of Outer for the receiver parameter's type.

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

I wouldn't expect a Signature attribute in Outer$Inner.class for the 
receiver parameter's type. See JVMS8 4.7.9.1 for the conditions when 
Signature is required. A receiver parameter is intended to be ephemeral 
- it's not a formal parameter and shouldn't be returned by anything in 
j.l.r.Executable concerned with formal parameters or their types.

The only representation of a receiver parameter in the class file is in 
Runtime[In]VisibleTypeAnnotations, for the benefit of 
Executable#getAnnotatedReceiverType.

Alex