javap and nullable projection types.

[Maurizio Cimadamore]

My understanding here is that we'll go down one of the two following paths:

1) extend Signature attribute to model nullable projections; then javap 
can consume this info directly

2) have unambiguous descriptor/value-projection mapping - e.g. LFoo 
always means Foo? - if we want something else (e.g. null-default Foo) we 
use some other descriptor letter

I think with either approaches javap (and javac's classreader) should 
always have enough info to do the inverse reconstruction?

Maurizio


On 21/04/2019 18:42, Srikanth wrote:
> While working on JDK-8222790 (javac diagnostics don't discriminate 
> between inline types and their nullable projection types.) I realized 
> that it is somewhat hard for javap to properly annotate nullable 
> projection types in its text output.
>
> A method in source of the form void foo(X x, X? xq) gets disassembled as
>
> void foo(X, X);
>     descriptor: (QX;LX;)V
>     flags: (0x0000)
>     Code:
>
> Note the parameter types both showing up as X. The descriptor is 
> correct, but the header is misleading.
> In general this looks unsolvable without the now withdrawn ValueTypes 
> attribute in the class file.
>
> This would be a problem for any tool that works only with a "local" 
> view without building an elaborate symbol table of all the classes 
> involved.
>
> Srikanth.