Change in type inference behaviour with JDK-8078024

[Liam Miller-Cushon]

Thanks for investigating, and for the detailed explanation. I'm glad to
hear that the new behaviour is valid.

Is it worth adding a regression test for this?

On Tue, Jul 7, 2015 at 7:02 PM, Vicente-Arturo Romero-Zaldivar <
vicente.romero at oracle.com> wrote:

>  Hi,
>
> I have modified the test case to:
>
> import java.util.Arrays;
> import java.util.List;
>
> class K {
>   public static <A> List<List<A>> cartesianProduct(List<? extends A>...
> lists) {
>     return cartesianProduct(Arrays.asList(lists));
>   }
>
>   public static <B> List<List<B>> cartesianProduct(List<? extends List<?
> extends B>> lists) {
>     throw new AssertionError();
>   }
> }
>
> In order to have different names for each type variable, now A and B.
>
> This corner case shows a semantic change of the patch for JDK-8078024.
> While determining the applicability of method:
>
> <B> List<List<B>> cartesianProduct(List<? extends List<? extends B>> lists)
>
> For which we have the constraints:
>
> B <: Object
> T <: List<? extends B>
> T<: Object
> List<? extends A> <: T
>
> First, variable B is selected for instantiation:
>
> B = CAP1 of ? extends A
> so this implies that:
>
> T <: List<? extends CAP1 of ? extends A>
> T<: Object
> List<? extends A> <: T
>
> OK now all the bounds are checked for consistency. While checking if
> List<? extends A> is a subtype of List<? extends CAP1 of ? extends A> a
> bound error is reported. Before the compiler was just swallowing it. As now
> the error is reported while variable B is being instantiated, the bound set
> is rolled back to it's initial state, B is instantiated to Object, and with
> this instantiation the constraint set is solvable, the method is
> applicable, it's the only applicable one and the code is accepted as
> correct.
>
>
> Thanks,
> Vicente
>
>
>
>
> On 07/07/2015 04:58 PM, Maurizio Cimadamore wrote:
>
> My understanding is that 8078024 should have been mostly a cleanup with
> performance-related issues (i.e. less time to converge to a non-existent
> solution). But Vicente did the work and might know few things more about
> this one, so let's hear from him.
>
> Maurizio
>
> On 07/07/15 22:34, Liam Miller-Cushon wrote:
>
> The fix for JDK-8078024 resolved an issue with type inference I was seeing
> with javac9. I can't tell from the bug report if that was deliberate.
>
> Could someone please confirm that the current behaviour is correct?
>
> Here's the repro. It fails with jdk9-dev @2888, and compiles cleanly
> @2889:
>
> === A.java ===
> import java.util.Arrays;
> import java.util.List;
>
> class A {
>   public static <B> List<List<B>> cartesianProduct(List<? extends B>...
> lists) {
>     return cartesianProduct(Arrays.asList(lists));
>   }
>
>   public static <B> List<List<B>> cartesianProduct(List<? extends List<?
> extends B>> lists) {
>     throw new AssertionError();
>   }
> }
> ===
>
> $ javac A.java
> A.java:6: error: incompatible types: inference variable B has incompatible
> bounds
>     return cartesianProduct(Arrays.asList(lists));
>                            ^
>     equality constraints: B
>     lower bounds: T,List<? extends B>
>   where B,T are type-variables:
>     B extends Object declared in method <B>cartesianProduct(List<? extends
> B>...)
>     T extends Object declared in method <T>asList(T...)
> Note: /usr/local/google/home/cushon/A.java uses unchecked or unsafe
> operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 error
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150708/43c27207/attachment-0001.html>