target_info structure of a method receiver
alex.buckley at oracle.com
Fri Sep 19 18:12:32 UTC 2014
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>
> Understod. Javac only allows Outer<T, U> as the receiver type (with
> optimal annotations). Neither Outer<String,String> nor the raw Outer
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 22.214.171.124 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
More information about the compiler-dev