30

I am trying to understand why the compiler is unable to resolve the bar method call. I would expect bar(Xyz::new) to always select bar(Supplier) as bar(T extends Xyz) can never match due to the upper bound on Xyz.

public <T extends Xyz> void foo(T s) {}
public <T extends Xyz> void bar(T s) {}
public <T extends Xyz> void bar(Supplier<T> s) {}

public void example() {
    foo(Xyz::new); // not valid (does not extend Xyz)

    bar((Supplier<Xyz>) Xyz::new); // valid (explicitly a Supplier)
    bar(Xyz::new); // ambiguous - but only one method is valid?
}

public static class Xyz {}

If bar(T) is not applicable, even when alone (as shown with foo(T)), then surely the only option is bar(Supplier) making this a non-ambiguous overload.

Why is the bar call ambiguous, especially when the foo and bar(T) calls are not valid resolutions themselves?

Runnable example of above code: https://www.jdoodle.com/ia/kqP

Timothy Cole
  • 304
  • 2
  • 7
  • Need more information, particularly details on what `Xyz` is, the exact actual error message, and the compiler version you're using. – chrylis -cautiouslyoptimistic- Nov 30 '21 at 22:02
  • 1
    @chrylis-cautiouslyoptimistic- `Xyz` is defined in the example, see the bottom of the source for `static class Xyz {}`. Occurs on all Java compilers that I have tested from Java 8 to Java 16. The error message is `reference to bar is ambiguous`. – Timothy Cole Nov 30 '21 at 22:15
  • I have attached a runnable example to the original post. Uncomment the labelled line to see the ambiguity error. – Timothy Cole Nov 30 '21 at 22:20
  • Please note that your analysis of the first error (_not valid (does not extend Xyz)_) is wrong. `foo(Xyz::new);` does not compile because the method `foo()` expects an instance of `Xyz` but you try to pass in a method reference which would require that `Xyz` is a functional interface - but `Xyz` is a class, not a functional interface. – Thomas Kläger Nov 30 '21 at 22:23
  • 3
    @ThomasKläger "*you try to pass in a method reference which would require that Xyz is a functional interface*" This is either outright wrong, or very badly phrased. If the param was declared as `Supplier` then `Xyz::new` would be a perfectly valid argument. A class does not need to be a functional interface to use method references. – Michael Nov 30 '21 at 23:03
  • @Michael may be the wording of my comment is bad but the argument still holds. _If the param was declared as `Supplier`_: then yes the code would work. But the param of `foo(T s)` is declared as `` and the Java compiler cannot convert the method reference `Xyz::new` into an instance of the concrete class `Xyz` or a subclass of `Xyz`. That is why the Java compiler writes this error message: "(argument mismatch; Xyz is not a functional interface)" for the line `foo(Xyz::new);` – Thomas Kläger Dec 01 '21 at 06:02
  • 3
    Type inference is *hard*. Basically any non-toy type system which mixes together stuff like generics, subtypes and the like will have a non-decidable typeinference problem. This means that, in order to have a working specification, you *must* restrict how type inference is done so that compilers can actually be written and agree on how the valid programs. This obviously means that some programs that could be inferred by some other algorithm wont be correctly inferred by the specification. In these cases usually adding explicit types can help since you switch from inferece to type checking. – GACy20 Dec 01 '21 at 09:04

2 Answers2

26

You're right that a smarter compiler should be able to resolve this unambiguously.

The way Java resolves method invocations is complex. It's defined by the JLS, and I make it 7500 words purely to determine how to resolve a method. Pasted into a text editor, it was 15 pages.

The general approach is:

  1. Compile-Time Step 1: Determine Type to Search (no issue here)
  2. Compile-Time Step 2: Determine Method Signature
    1. Identify Potentially Applicable Methods
    2. Phase 1: Identify Matching Arity Methods Applicable by Strict Invocation
    3. Phase 2: Identify Matching Arity Methods Applicable by Loose Invocation
    4. Phase 3: Identify Methods Applicable by Variable Arity Invocation
    5. Choosing the Most Specific Method
    6. Method Invocation Type
  3. Compile-Time Step 3: Is the Chosen Method Appropriate?

I don't understand anywhere close to all of the details and how it pertains to your specific case. If you care to dive into it then I've already linked the full spec. Hopefully this explanation is good enough for your purposes:

Ambiguousness is determined at step 2.6, but there is still a further appropriateness check at step 3. Your foo method must be failing at step 3. Your bar method never makes it that far because the compiler still considers both methods to be valid possibilities. A human can make the determination that the non-appropriateness resolves the ambiguity, but that's not order the compiler does things. I could only speculate why - performance might be a factor.

Your code is operating at the intersection of generics, overloading and method references, all three of which were introduced at different times; it's not massively surprising to me that the compiler would struggle.

Michael
  • 41,989
  • 11
  • 82
  • 128
  • 6
    I don't know about Java, but for C#, overload resolution is famously NP-complete and can be used to solve, e.g. 3-SAT *at compile time*. While the rules are different, the problem to solve is fundamentally the same, so I would not be surprised at all if Java's overload resolution is similarly complex (both in the general English sense of the word and the specific Computer Science "Computational Complexity" one). – Jörg W Mittag Dec 01 '21 at 13:06
  • 1
    One point about Java is that it tries to exactly specify how code is to be compiled - without any "blind spots." It may have been easier to describe a less smart algorithm – user253751 Dec 01 '21 at 15:00
  • @user253751 Yes, absolutely. Just because it should be *possible* to achieve this, doesn't mean that it's feasible to do so. It could cause the spec to get significantly more complex (i.e. error-prone to implement), or compilation times to increase, or result in additional undesirable corner cases elsewhere. – Michael Dec 01 '21 at 15:12
  • "[Java] tries to exactly specify how code is to be compiled" - Either your specification is written in human prose or it's in the code of the reference implementation. You don't really have any other options. – Nayuki Dec 01 '21 at 19:02
  • 1
    @JörgWMittag On a related note: Java's type checking / generics even are Turing complete. @ Nayuki Arguably, a third option is a mathematically precise defintion (which does not have to be constructive) – incaseoftrouble Dec 07 '21 at 23:14
18

Your problem is mostly a problem of type inference than a problem of ambiguous method:

public <T extends Xyz> void bar(T s) {} // bar(Xyz)
public void bar(String s) {}
public <T extends Zyx> void bar(T s) {} // bar(Zyx)
public <T extends Xyz> void bar(Supplier<T> s) {}
public static class Xyz {}
public static class Zyx {}

If you use:

    bar(new Xyz());  // ok
    bar("a");   // ok
    bar(new Zyx());   // ok
    bar((Supplier<Xyz>) Xyz::new); // ok
    bar(Xyz::new); // ambiguous

You get this error (tried with Java 17) which is not about the lambda, but about the type T: cannot infer type-variable(s) T

  both method <T#1>bar(T#1) in Example and method <T#2>bar(Supplier<T#2>) in Example match
  where T#1,T#2 are type-variables:
    T#1 extends Zyx declared in method <T#1>bar(T#1)
    T#2 extends Xyz declared in method <T#2>bar(Supplier<T#2>)
Example.java:18: error: incompatible types: cannot infer type-variable(s) T

Java is not smart enough to find the concrete type T is this case, and you have to help it:

Example.<Xyz>bar(Xyz::new);

I tried to look into the JLS, driven by Michael answer, and the section that should better answer your question is the 18.5.1. Invocation Applicability Inference.

I had the same kind of errors frequently occurring with Java 7 and Collections:

public static <T extends Zyx> void bar(java.util.List<T> s) {} // bar(Zyx)
public static <T extends Zyx> void bar(T s) {} // bar(List)
bar(new Zyx()); 
bar(java.util.Collections.emptyList());

The worse of it being that Eclipse was having no trouble, while javac failed.

I suppose that in the case of lambdas, the compiler does not infer the type T from the "Xyz".

NoDataFound
  • 11,381
  • 33
  • 59