7

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?

Improve this question
7
  • 2
    More info: compiles fine in javac 1.8.0_25, 1.8.0_40, ecj 3.10.2; fails with the same message in javac 1.9.0-ea-b72. More interesting is that replacing i -> new String[i] with String[]::new fixes the problem in javac 1.9.0-ea-b72. Commented Aug 26, 2015 at 10:22
  • 2
    i believie it is fixed, i tried it in ideone, and it is using sun jdk 8u51 here is link ideone.com/wvCXyO Commented Aug 26, 2015 at 10:24
  • And with jdk1.8.0_60 replacing i -> new String[i] with String[]::new doesn't fix the problem. Commented Aug 26, 2015 at 10:33
  • 1
    Changing i -> new String[i] to String[]::new fixes the problem and so does (int i) -> new String[i] so at least there is a recognizable pattern… Commented Aug 26, 2015 at 11:19
  • @assylias I download the lastest jdk8u60 for linux and can reproduce it from command line. Commented Aug 26, 2015 at 11:24

2 Answers 2

Reset to default
1

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

2022, and this bug is still in javac. Do you know whether there’s a related bug report?
1

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.

Improve this answer

1 Comment

A jvm bug wouldn't explain the compile error, but the bug you cite is actually assigned to javac. OTOH, that bug was fixed for 8u20 so the fix is available in all versions mentioned in the question plus comments.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.