target_info structure of a method receiver

[Joel Borggren-Franck]

Hi Alex,

Thanks for the clarification. Makes sense, however there is still
something with the receivers that feel problematic:

--- 8< ---

public class Outer<@B T, @C U> {

    class Inner {

       Inner(@A Outer<@NotB T, @NotC U> Outer.this) { ... }

    }
}

--- 8< ---

Focusing on the inner class' constructor receiver parameter, JLS 8.4.1
says:

" In an inner class's constructor, the type of the receiver parameter
must be the class or interface which is the immediately enclosing type
declaration of the inner class, and the name of the receiver parameter
must be Identifier . this where Identifier is the simple name of the
class or interface which is the immediately enclosing type declaration
of the inner class; otherwise, a compile-time error occurs."

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? What is the relation between the annotations on the
receiver type's type parameters and the receiver type declaration's
annotations on the type parameters?  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?

Does any of this make any sense?

I think the underlying question here is what is the meaning of that
receiver type parameter, and what should we do at runtime? 

cheers
/Joel

On 2014-09-12, Alex Buckley wrote:
> I know what you mean, but there is no problem with javac here.
> 
> The only way to explain this precisely is to use a JLS concept. Per
> JLS8 4.11, a receiver parameter induces one type context - think of
> it as the area in Foo's ctor signature after '(' and before
> 'Receiver.this'. It is this type context of which there is "only
> one". There may be many types "inside" the type context if a nested,
> array, or parameterized type is involved, and the target_path
> structure will take care of getting you to a particular one - but
> there's only one area.
> 
> Same deal with the type context for a field declaration - you
> already know the field (the attribute is within a field_info) so
> there is only one area where the type of the field can be written.
> Contrast with a formal parameter declaration - the attribute is
> inside a method_info so there needs to be a way to identify a
> particular formal parameter (formal_parameter_target) which provides
> the area (type context) where the type of the formal parameter can
> be written.
> 
> I'm not sure it's worth rewriting the informative JVMS text. The
> normative text for empty_target already mentions "_the_ type in a
> field declaration" and "_the_ receiver type of a method or
> constructor", and there are other mentions of "_the_ type"
> throughout 4.7.20.1. Appealing to "the type context" rather than
> "the type" seems more trouble than it's worth.
> 
> Alex
> 
> On 9/12/2014 7:58 AM, Joel Borggren-Franck wrote:
> >Hi,
> >
> >The table 4.7.20-A and section 4.7.20.1 in JVMS says that a method
> >receiver target kind is followed by the empty_target target info, noting
> >that "Only one type appears in each of these locations, so there is no
> >per-type information to represent in the target_info union.", yet the
> >following program compiles with both 8 and 9 javac:
> >
> >--- 8< ---
> >
> >import java.lang.annotation.*;
> >import java.lang.reflect.*;
> >
> >public class Receiver<T, U> {
> >
> >    @Target(ElementType.TYPE_USE)
> >    @Retention(RetentionPolicy.RUNTIME)
> >    @interface A {
> >    }
> >
> >    class Foo {
> >       Foo(@A Receiver<@A T, @A U> Receiver.this) {
> >       }
> >    }
> >
> >    public void m(@A Receiver<@A T, @A U> this, int j) { ; }
> >}
> >
> >--- 8< ---
> >
> >Isn't this 3 type uses in both the ctor and the method?
> >
> >I haven't found anything in JLS to indicate if javac or JVMLS is wrong
> >here.
> >
> >cheers
> >/Joel
> >