LVTI: as per spec upward projection couldn't have resulted in a '? extends' parameterization

[Dan Smith]

> On Oct 12, 2017, at 1:56 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> 
> On 12/10/17 18:53, Georgiy Rakov wrote:
>> According to this error message javac assumes type of 'z' to be Shell<? extends C1>. It seems that this is at least a cosmetic defect since type of 'z' is Shell<?> as it's been clarified.
>> Should a JBS issue be filed on javac for this reason?
> Hi,
> based on Dan's explanation this would seem as a cosmetic issue indeed. The compiler impl is based off an earlier version of this spec which did not include this rule. That said, I can't  think of a case in which the difference will be visible. As Dan said, Shell<?> will be captured and the capture variable it leads to will be the same, so membership-wise no difference can be observed.
> 
> Dan, can you think of cases in which some weird difference would pop up?
> 
> Maurizio

I was thinking this may just be an artifact of the weird way javac represents wildcards and their implicit bounds.

You may get different results from subtyping depending on whether Shell<? extends C1> or Shell<?> appears in a type, but it's hard to be sure due to anomalies in how wildcards and capture vars and specified and implemented. Any difference you observe is probably a bug, under the type system cleanup umbrella.

And it may be impossible to exploit any difference between the two types, because upward projection will not place the type in an "invariant" position, and type equivalence testing is typically where you'd see a difference.

—Dan