Type annotations and this-reference (receiver) in methods

[Alex Buckley]

Andre,

While the Signature attribute mechanism can represent parameterized 
types and type variables in a class file, it is not appropriate for 
testInnerNew. A Signature attribute is meant to record a method's Java 
type signature, which officially does not include a formal parameter 
representing 'this'. The formal parameter representing 'this' appears in 
the descriptor of testInnerNew, as you noted, but the point of the 
Signature attribute is to give Java-level types, not bytecode-level types.

That said, this is really all moot, since the broader problem is that it 
is not possible to record the signatures of annotated parameterized 
types where they appear in a method body, e.g. in a qualified class 
instance creation expression of a parameterized type. JSR 308 didn't 
attempt to solve this problem.

Alex

On 2/8/2014 11:29 AM, André Pankraz wrote:
> Hi,
>
> thx so far for the other answers, next remark ;)
>
>
> Regard the following (artificial) code example.
> Just focus onto the first parameter in "testInnerNew(Inner this)", don't
> had time to create a minimalistic example, just want to explain my issue:
>
> ------
>      class Outer<W> {
>
>          class Middle {
>
>              class Inner extends
>                      Outer<@Size(max = 21) String>. at Size(max = 22) Middle {
>
>                  @Nonnull
>                  Inner testInnerNew(
>                          Outer<@Size(max = 24) W /* <W> is necessary!
> */>. at Nonnull @Size(max = 25) Middle. at Size(max = 26) Inner this,
>                          @Size(max = 27) Integer arg) {
>                      // Eclipse Bug?: Outer<String> not allowed
>                      return new Outer. at Size(max = 28) Middle. at Size(max =
> 29) Inner(
>                              arg);
>                  }
>
>              }
>
> ----
>
> In my eyes we have a problem here with the missing signature of the
> first parameter on the method testInnerNew(), which isn't a real
> argument in bytecode but is just syntactix sugar in Java to add type
> annotations to the receiver type for the method callout.
>
> Now with the choosen architecture to store type annotations in seperate
> attributes and add all this type path stuff to it, you now are heavily
> dependent on matching descriptors, signatures and inner/outer type
> information - or you cannot apply the type path properly. (I still don't
> understand this architecture, but different topic...)
>
>
> If I want to apply the @Size(max = 24) at the given position I need the
> full signature of this parameter, inclusing parameterized types with
> type variable W.
> It isn't in the bytecode (and cannot be, is not a real parameter there).
>
> So you could suggest to just create the signature of the given
> information, because the first artificial "this" parameter has the
> constraint to be exactly the same like the enclosing types. This means I
> have to:
> * go through all enclosing types (need all inner/outer type info and
> descriptors here)
> * for all enclosing types that have type parameters, I create a
> parameterized type with type variables, that match the type parameter names
> * create a fully qualified type from this
>
> Yes...I tried it, but then I noticed, that now you are dependent from
> the fact, that all enclosing classes are already parsed first, or you
> cannot get their type parameters.
> Till now each class has all relevant info by itself (e.g. all
> inner/outer info for all referenced classes) - now this would change.
> So I could reorder my classes...on the other side not that easy if you
> directly read JARs / later Pack2000 on the fly to build a full type model.
>
> Is this intentional? Or is there a mistake in my remarks?
>
>
> Cheers,
> André
>
>
>
>