target_info structure of a method receiver

[Joel Borggrén-Franck]

Hi,

On 19 sep 2014, at 20:12, Alex Buckley <alex.buckley at oracle.com> wrote:

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

As long as I can expect exactly one type for the receiver type (excluding annotations) this shouldn’t be a problem. This seems consistent with how javac works today and what you wrote above. Thanks for explaining this.

cheres
/Joel