JDK-7120463 : Fix method reference parser support in order to avoid ambiguities
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown
  • Submitted: 2011-12-12
  • Updated: 2012-04-20
  • Resolved: 2012-04-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b19Fixed
Related Reports
Relates :  
JDK-7115052 - Add parser support for method references
Description
The initial support for method reference parsing contained did not handle well an ambiguity between unbound method references and binary expression:

class Test {
   void test() { that(i < len, "oopmap"); }
   void that(int i, String s) { };
}

The above code failed to compile, as the compiler tried to parse the sequence 'i' '<' 'len' as an unbound method reference (whose qualifier is a generic type).
Comments
SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1ae5988e201b
20-12-2011
EVALUATION This ambiguity should be resolved by using lookahead. When the parser sees an identifier, followed by a '<' terminal, a routine should leverage lookahead to check for the matching '>' symbol (skipping any nested '<', '>' symbols). If this is indeed a method reference, the terminal following the '>' would be either a '.', as in: Foo<String>.Bar<Integer>#m or a '#' as in: Foo<String>#m If neither terminal is found after the '>', the parser can safely assume that this is not an unbound method reference.
12-12-2011