javap and nullable projection types.

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "John Rose" <john.r.rose at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Vendredi 10 Mai 2019 22:39:17
> Objet: Re: javap and nullable projection types.

> On 10/05/2019 20:57, John Rose wrote:
>> I suggest that javap could render old signatures
>> the old way and new signatures with a non-Java
>> marker, like this:
>>
>>    void bar(Point? flat, Point ptr) { … }
>>
>>    void bar(inline mypkg.Point, mypkg.Point)
>>      descriptor: (Qmypkg/Point;Lmypkg/Point;)V
>>      flags: (0x0000)
>>
>> That's not out of bounds.  Maybe our problem here
>> is shaping the boundary of javap.  It should not
>> try to pretend it's a decompiler, and by definition
>> shouldn't try to guess at def-site information outside
>> of the classfile it is rendering.  It's just printing one
>> classfile, at the JVM level.  So adding V? annotations
>> looks like the wrong move, at this level.
> 
> 
> Uhm - not convinced by this. In general, javap is always able to
> reconstruct the signature of a given call, as it occurred in the source
> code.
> 
> We can, as you suggest, introduce a disconnect and treat new types with
> a character that's not what occurs in the source code, but that would be
> the first time such a move is being played, so people will be surprised.
> 
> But let me retrace the steps that led me to some compiler/tool-specific
> attribute like ValueTypes (which would be ignored by the VM, as you say,
> it's not sharp enough).
> 
> If we had such an attribute, then javap could look at the signature:
> 
> * QV; -> this is a Q type (or a N-type, or...)
> * LV; -> suspend judgment - look at the ValueType table:
>    - V is in the table - then render as V?
>    - V is not in the table - then render as V
> 
> This is a simple way to provide disambiguation w/o enhancing signature
> attribute. I'm a bit wary of going down the signature attribute path
> because that's a really big hammer, which has ramifications in the API,
> etc. It seems like in 90% cases, a descriptor will tell us the info we
> need; we just need a little help for cases where LV; is ambiguous - are
> we sure we need the Signature bazooka for that (when a per-class list of
> names is just fine) ?

I agree with Maurizio and i think we have no choice here because it's not rare to have programs that use the reflection API or ASM to generate the source code of an interface of a class (that will be proxified at runtime by example), if view of the compiler is not accessible from the .class only, it means those tools will not be able to reconstitute the Java view of code, thus will stop working.

> 
> Maurizio

Rémi