[jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference
Maurizio Cimadamore
mcimadamore at openjdk.java.net
Tue Jan 12 10:37:56 UTC 2021
On Tue, 12 Jan 2021 02:21:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:
> This patch fixes the following issue, for code like:
> import java.util.function.*;
>
> public class Test {
> public String foo(Object o) { return "foo"; }
> public static String foo(String o) { return "bar"; }
>
> public void test() {
> Function<String, String> f = Test::foo;
> }
> }
> javac is issuing an invalid method reference error even though the static method is applicable. This is due to a regression on the implementation of the following assertion on section 15.13.1 of the JLS 14:
>
> If the first search produces a most specific method that is static , and the set
> of applicable methods produced by the second search contains no non- static
> methods, then the compile-time declaration is the most specified method of
> the first search.
>
> Apart from fixing the mentioned regression, this patch also adds a debug feature for the compiler to print out the findings during the search for an applicable method reference. The information is printed out if a debug flag is passed to the compiler.
>
> TIA
The debugging logic seems good, but I don't get how the fix is supposed to work, since it seems to replicate the behavior that's already there. I'm probably missing something.
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3327:
> 3325: @Override
> 3326: ReferenceLookupResult unboundResult(ReferenceLookupResult boundRes, ReferenceLookupResult unboundRes) {
> 3327: if (boundRes.isSuccess() && boundRes.sym.isStatic() &&
For consistency here I'd prefer to see `boundRes.hasKind(StaticKind.STATIC)` (which is set if the underlying symbol is static). E.g. I think the fix here is really adding the `isSuccess` part, not changing the static check.
-------------
PR: https://git.openjdk.java.net/jdk16/pull/107
More information about the compiler-dev
mailing list