Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8296171

Compiler incorrectly rejects code with variadic method references

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • 20
    • 15, 16, 17, 18, 19, 20
    • tools
    • None
    • b24

      Consider the program below, originally reported here:
      https://old.reddit.com/r/java/comments/yhlv52/strange_behaviour_of_javac_15_16_17_18_19/

      import java.util.function.*;

      interface Intf {
          Object apply(String... args);
      }

      class Test {
         public final Object foo(Object... o) { return "foo"; }
         public static Object foo(Object o) { return "bar"; }

          public void test() {
              Intf f = this::foo;

              System.out.println(f.apply());
          }

          public static void main(String[] args) {
              new Test().test();
          }
      }

      When checking the method reference, both 'foo' methods are applicable methods to the parameter types Object[] (this is the parameter type derived from the functional descriptor).

      The compiler should then pick the most specific: since we have determined applicability w/o resorting to variadic conversions, we should just use plain subtyping to prove most specific. Hence, foo(Object...) is more specific than foo(Object) because Object[] <: Object but not vice-versa.

      But the compiler still reports an error, as if the most specific method was the static method, which is confusing.

      After debugging, it seems like the compiler correctly identifies the most specific method, but then is getting confused by the fact that _one_ applicable static method was found during the search. While this is an important fact to record in case the method reference could be unbound (e.g. TypeName::methodName), this fact is immaterial in the method reference lookup in this example, given the qualifier expression is not a type name, but a plain expression.

            vromero Vicente Arturo Romero Zaldivar
            mcimadamore Maurizio Cimadamore
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: