[jdk16] RFR: 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference

[Maurizio Cimadamore]

On Tue, 12 Jan 2021 16:39:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> That said - I'm having issue understanding how this has been fixed: if the fix search succeeds and the second search fails to produce a non-static method, then the first search should be preferred. It seems to me that the old code already covers that? Note that `isSuccess` is true whenever the kind != UNDEFINED, so if we check that kind should be STATIC, we already check that is a successful lookup and that the result is static. In other words, I don't see how the new code is different from the old?
>
> I guess that the difference between the new code and the previous one is that in the old code when we check if `boundRes.hasKind(StaticKind.STATIC)` we are checking for a global property of all candidates, meaning that for the previous check to be true, all candidates have to be static. And this is not what the spec is saying, as the spec cares about the staticness, or lack of it, of the most specific method found in each search. Does this make sense?

Ok - I missed that both symbols are applicable in the first search. So while the most specific symbol is the static one, the StaticKind is set to BOTH, since one is static and the other is not. So, yes, using StaticKind for things like "the first/second search returned a static/non-static method" is incorrect. Your patch fixes that.

I'm dubious as to whether isSuccess is correct though. E.g. isSuccess returns true whenever the StaticKind is != UNDEFINED - but that would also return true in cases where there's an ambiguity in the first search - which I would not describe as a success. Do you agree? If so, can we add a test for that case (e.g. a case where the first search has ambiguous result) and see what happens?

-------------

PR: https://git.openjdk.java.net/jdk16/pull/107