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

Compiler incorrectly rejects code with variadic method references

    XMLWordPrintable

Details

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

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: