RFR: JDK-8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference

[Maurizio Cimadamore]

I was thinking the same as Jon - this is tricky area - there are two 
separate lookup steps, each of which can have different results and then 
the method reference is selected according to some criteria between the 
two results. We had an history of issues in this area and, while the 
code is much more in sync with the spec than it used to be (which 
allowed for a relatively speedy fix), I think that the fact that we're 
still finding issues with it points at the fact that some better testing 
methodology is required.

Generating combination automatically might not be the best way to 
approach this either - given that we would then need somehow to 
replicate all the complex machinery to decide which method reference 
gets resolved in the test itself, and that machinery can in itself be buggy.

This is probably a case of spending a week or two combing through the 
spec, and maybe putting together a 'light' framework, like the one for 
records [1] or for 'var' [2] which allows to add new tests in relatively 
little time, so that we can add many variants by hand, testing the 
various corners of the spec logic.

Maurizio

[1] - 
https://hg.openjdk.java.net/jdk/jdk/file/8e76f81d057a/test/langtools/tools/javac/records/RecordCompilationTests.java
[2] - 
http://hg.openjdk.java.net/jdk/jdk/file/tip/test/langtools/tools/javac/lvti/harness/NonDenotableTest.java

On 11/12/2019 18:49, Jonathan Gibbons wrote:
> The basic fix is OK.
>
> The test is a little light and may be a candidate for a follow-up fix 
> to provide a small combo test covering static/non-static 
> bound/unbound, and maybe verifying error messages.
>
> -- Jon
>
>
>
> On 12/11/2019 10:20 AM, Vicente Romero wrote:
>> Hi,
>>
>> Please review this P4 targeted to 14. Javac is failing to check the 
>> staticness of the most specific candidate, instead it is checking the 
>> staticness of all the possible candidates. This patch fixes that issue.
>>
>> Thanks,
>> Vicente
>>
>> PS, the fix was originally developed by Maurizio
>>
>> http://cr.openjdk.java.net/~vromero/8231461/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8231461
>