JDK-8055963 : Inference failure with nested invocation
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8u20,8u40
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-08-25
  • Updated: 2022-07-07
  • Resolved: 2014-09-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u60Fixed 9 b32Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
The following fails to compile:

---

public class FirstNonNull {

public static class C<T> {}

public static <T> T firstNonNull(T first, T second) {
    return first != null ? first : second;
}

public static C<String> doesNotCompile = firstNonNull(new C<String>(), new C<>());

}

---

Error:

public static C<String> doesNotCompile = firstNonNull(new C<String>(), new C<>());
                                                     ^
    inferred: C<? extends Object>
    upper bound(s): C<String>,Object

---

This is a regression -- it compiles correctly with the initial release of JDK 8.

Reported on Stack Overflow: http://stackoverflow.com/questions/25490581
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/c419bddef7f3 User: lana Date: 2014-09-24 20:47:23 +0000
24-09-2014

URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c419bddef7f3 User: mcimadamore Date: 2014-09-15 11:44:06 +0000
15-09-2014

Yes, I agree with Maurizio. Missed that part in my original comment. Resolution: the spec is unclear about the treatment of non-proper types here, and in practice the early resolution rule should not be applied in this example. See JDK-8056092.
29-08-2014

I think this should apply: "T is a reference type, but is not a wildcard-parameterized type, and either i) B2 contains a bound of one of the forms α = S or S <: α, where S is a wildcard-parameterized type, or ii) B2 contains two bounds of the forms S1 <: α and S2 <: α, where S1 and S2 have supertypes that are two different parameterizations of the same generic class or interface. " As, t has two lower bounds, C<String> and C<s> respectively. The only way I see this not applying here is if you intend to apply the rule only if S1 and S2 are proper types - but in that case the spec rules should need a clarification?
26-08-2014

Here's an overview of the specified behavior. Argument constraints (18.5.1): C<String> --> t C<s> --> t Resulting bound set: { t <: Object, C<String> <: t, s <: Object, C<s> <: t } Resolution test (18.5.1): s = Object t = lub(C<String>, C<Object>) = C<?> Target type constraint (18.5.2): t --> C<String> C<s> <: C<String> Resulting bound set: { t <: C<String>, C<String> <: t, s = String } Resolution (18.5.2): s = String t = C<String>
25-08-2014