javap and nullable projection types.

[Maurizio Cimadamore]

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) ?

Maurizio