Change in type inference behaviour with JDK-8078024

[Vicente-Arturo Romero-Zaldivar]

On 07/08/2015 01:16 PM, Liam Miller-Cushon wrote:
> 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?

Yes it is. I will create a bug report for it.

Thanks,
Vicente

>
> On Tue, Jul 7, 2015 at 7:02 PM, Vicente-Arturo Romero-Zaldivar 
> <vicente.romero at oracle.com <mailto: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/8d4bdaab/attachment.html>