JDK-8079630 : generic method call passed as varargs argument regression
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8u40
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux_ubuntu
  • CPU: x86_64
  • Submitted: 2015-03-16
  • Updated: 2016-01-22
  • Resolved: 2016-01-22
Related Reports
Relates :  
JDK-8033483 - Should ignore nested lambda bodies during overload resolution
Description
FULL PRODUCT VERSION :
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

A DESCRIPTION OF THE PROBLEM :
The following works with 1.8.0_11 and the Eclipse Java compiler:

public class Bug {
	public static void main(String[] args) {
		foo(bar(true, b -> b ? 1 : 0));
	}

	public static void foo(int... baz) { }

	public static <R, A> R bar(A arg, java.util.function.Function<A, R> f) {
		return f.apply(arg);
	}
}

1.8.0_40 error message:

Bug.java:3: error: incompatible types: inferred type does not conform to upper bound(s)
                foo(bar(true, b -> b ? 1 : 0));
                       ^
    inferred: Integer
    upper bound(s): int[],Object
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
1 error

REGRESSION.  Last worked in version 8u11


REPRODUCIBILITY :
This bug can be reproduced always.
Comments
This started to fail after JDK-8033483, which clarified the behavior of overload resolution with implicit lambdas. Prior to the fix, javac was erroneously looking inside the implicit lambda (which is not pertinent to applicability), deriving a constraint of the kind R :> int. This cause method 'foo' only to be applicable during the vararg step - which then causes the inference process to terminate correctly. After the fix, the method is still applicable, but since the contents of the lambda are not inspected, there's no constraint on R - meaning that R is free to receive the constraint from the varargs method R <: int[] (this now occurs prior varargs expansion takes place). As a result, when we later apply invocation type inference, and use the set of constraints derived above, we find a mismatch, as the lambda is forcing R :> int, but we also have an upper bound like R <: int[] - hence the failure.
22-01-2016