Change in type inference behaviour with JDK-8078024

[Vicente-Arturo Romero-Zaldivar]

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/20150707/fb8982b4/attachment.html>