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