RFR 8188144: regression in method reference type-checking

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Sep 29 16:42:17 UTC 2017


Hi,
here's a patch for a regression in method reference type checking:

http://cr.openjdk.java.net/~mcimadamore/8188144/

JLS 15.13.1 defines the process for resolving a method reference - this 
is a two step process, where two searches are performed. It is sometimes 
possible for both searches to produce a result - when that happens, 
there are a bunch of rules which tell us what search wins:

" 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"

And again:

"Otherwise, if the set of applicable methods produced by the first 
search contains no |static| methods, and the second search produces a 
most specific method that is non-|static|, then the compile-time 
declaration is the most specific method of the second search."

Javac has been rectified to correctly implement this logic as part of:

https://bugs.openjdk.java.net/browse/JDK-8068995

However, in the degenerate case where both searches return _the same_ 
method, the rectified logic doesn't work. This is caused by the fact 
that we use the resolved symbol to 'infer' which search (first or 
second?) gave us the desired result. Note that it is important for javac 
to know which search produced the result as that will affect code 
generation (is this a bound or an unbound method reference?).

Since we already had all the desired information in the class called 
ReferenceLookupResult - introduced as part of JDK-8068995, I have 
tweaked the ReferenceChooser::result signature to return one of those 
guys instead of a plain Symbol - this allows us to reconstruct the 
correct picture before returning control to Attr.

Cheers
Maurizio


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170929/15ecf996/attachment.html>


More information about the compiler-dev mailing list