CODEWITHSUNDEEP
javajava-8
And390
And390

Reputation: 1560

Can't resolve overloaded method with generic lambda

This code:

public static void f(String[] args)  {}
public static void f(Integer[] args)  {}

public static void main(String[] args)
{
    f(Stream.of("xxx").toArray(i -> new String[i]));
}

compiles success with jdk8u45 but jdk8u60 prints the following error:

Error:(17, 9) java: reference to f is ambiguous
  both method f(java.lang.String[]) in type_infer.Test and method f(java.lang.Integer[]) in type_infer.Test match

Does it follow the JSL, Why compiler can not resolve overloaded methods? Was it a fixed bug in jdk8u45?

Upvotes: 7

Views: 1358

Answers (2)

Stephan Herrmann
Stephan Herrmann

Reputation: 8178

This looks like a bug recently introduced in javac.

The argument in the call to f(..) is clearly of type String[]. This can, e.g., be shown by resolving the same expression as a standalone expression:

String s1 = Stream.of("xxx").toArray(i -> new String[i])[0];
String[] s2 = Stream.of("xxx").toArray(i -> new String[i]).clone();

These are accepted by all versions of compilers.

Clearly, f(Integer[]) is not applicable with an argument of type String[]. I see no reason why the outer type inference would force the inner resolution to a worse result (e.g., Object[]) than resolution as a standalone expression.

Additional evidence: the following statement is correctly rejected even by those versions of javac affected by this bug:

Integer[] s3 = Stream.of("xxx").toArray(i -> new String[i]);

Hence f(Integer[]) is clearly out of the reckoning.

Upvotes: 1

jorgeu
jorgeu

Reputation: 689

You're getting the pain from a known bug in the jvm http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8029718 Not sure how to relate the "fixed version" to the builds available at Oracle website. But anyway you should work in the latest version and report your findings in that bug. Maybe they fixed it and now there is a regression.

Upvotes: 1

Related Questions