RFR 8191802: Upward projection result is A<? extends Number> instead of A<? super Integer>

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Nov 24 17:39:59 UTC 2017


Hi,
please review the fix for JDK-8191802:

http://cr.openjdk.java.net/~mcimadamore/8191802/

This is a conformance issue with local variable type inference - the 
specification text for upper projection says this (section 4.10.5):

"The upward projection of a type T with respect to a set of restricted 
type variables is defined as follows:

     [...]

     If T is a parameterized class type or a parameterized interface 
type, G<A1, ..., An>, then the result is G<A1', ..., An'>, where, for 1 
≤ i ≤ n, Ai' is derived from Ai as follows:

         [...]
         If Ai is a type that mentions a restricted type variable, then 
Ai' is a wildcard. Let U be the upward projection of Ai. There are three 
cases:
*If U is not Object, and if either the declared bound of the ith 
parameter of G, Bi, mentions a type parameter of G, or Bi is not a 
subtype of U, then Ai' is an upper-bounded wildcard, ? extends U.*
             Otherwise, if the downward projection of Ai is L, then Ai' 
is a lower-bounded wildcard, ? super L.
             Otherwise, the downward projection of Ai is undefined and 
Ai' is an unbounded wildcard, ?."

The text in bold is not implemented accurately by javac. What javac used 
to do was simply to throw away the upper bound and favor the lower bound 
if the upper was Object.

The spec text is much more subtle and precise, allowing javac to throw 
away upper bounds that do not add any extra information w.r.t. declared 
bounds.

As a result of this change, there are few places where the compiler used 
to infer A<? extend B> (where B was same type as declared bound) and now 
it infers A<?> as per spec - this caused few changes in the jshell test 
TypeNameTest.

I've added a lvti harness test to verify the assertions in the above 
paragraph.

Cheers
Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171124/21a17ab3/attachment.html>


More information about the compiler-dev mailing list