Inferred type issue with Java 1.8.0_65

Question

So, I have the following code:

public class Tester {
    public static void doAssert(Object foo, Object bar) {
    }

    public static void doAssert(Object[] foo, Object[] bar) {
    }

    public static <T> T getValue(String name, Function<String, T> covert) {
        return null;
    }

    public static void main (String[] args) {
        doAssert(getValue("", Double::valueOf), null);
    }
}

If I compile this with javac v1.8.0_05, this works fine. Under 1.8.0_65, I get the following error (as reported with -Xdiags:verbose):

Tester.java:32: error: method doAssert in class Tester cannot be applied to given types;
            doAssert(null, getValue("", Double::valueOf));
                    ^
  required: Object[],Object[]
  found: <null>,Double
  reason: argument mismatch; inferred type does not conform to upper bound(s)
      inferred: Double
      upper bound(s): Object[],Object
1 error

This goes away if I explicitly cast the null argument to Double, or if I remove the Object[] overload of doAssert.

So...is this a regression in 1.8.0_65 or one of the other intervening releases, or was 1.8.0_05 overly permissive? And why can't javac figure out what it's supposed to do?

(re: the close vote - to me, it's non-obvious how the other Q&A is a duplicate; the linked questions don't appear to deal with method overloading issues, which is required to reproduce this issue.)

I reproduced this error with 1.8.0_60 (note: Eclipse Mars 4.5.1 compiles it fine). IMO this should compile fine. — Tunaki, Nov 05 '15 at 19:51
Possible duplicate of [Is there a type inference regression in JDK 8 update 20?](http://stackoverflow.com/questions/25490581/is-there-a-type-inference-regression-in-jdk-8-update-20) — David Conrad, Nov 05 '15 at 20:59
well -- should it compile? overload resolution depends on argument types; yet here argument types need to be inferred from parameter types, which requires overload resolution being done first ... this is not a trivial problem. Good luck reading the spec - the compiler writers did :) — ZhongYu, Nov 05 '15 at 22:01
@bayou.io if you think that shouldn't compile, can you provide a slightly more detailed explanation as to why? Esp. if it included the relevant JLS bits, that'd be a very helpful answer. — Sbodd, Nov 05 '15 at 22:08
anyhow, overloading is never a necessity - use a different method name:) Java is far more sophisticated in support overloading than most languages, but it may still fail — ZhongYu, Nov 05 '15 at 22:18
Sadly, the overloaded method in my real code is in a 3rd-party library, so "don't overload it" is not an immediate answer. — Sbodd, Nov 05 '15 at 22:28

score 1 · Answer 1 · answered Nov 05 '15 at 20:10

In the update 20 changelog one of the features added was:

Java Compiler updated

You can see the amount of bugs related to javac and parameters inference here: http://www.oracle.com/technetwork/java/javase/2col/8u20-bugfixes-2257730.html

In some bugs (f.e: http://bugs.java.com/view_bug.do?bug_id=8046762) some new additions were reverted. Maybe this could be the cause for the javac behaviour in update 65 and explain it was working in update 5 too.

Inferred type issue with Java 1.8.0_65

1 Answers1