JDK-6481655 : Parser confused by combination of parens and explicit type args
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6,6u23,7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux,windows_7
  • CPU: generic,x86
  • Submitted: 2006-10-13
  • Updated: 2011-05-18
  • Resolved: 2011-05-18
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 7
7 b27Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
Consider the following program, Util.java:

public class Util {
    @SuppressWarnings("unchecked")
    public static <T> T cast(Object x) {
	return (T) x;
    }

    static {
	Util.<Object>cast(null);
	(Util.<Object>cast(null)).getClass();
    }
}

The first statement in the static initializer compiles without problems.  But the second statement produces the following error:

Util.java:9: illegal start of expression
        (Util.<Object>cast(null)).getClass();
              ^

Various experiments show that it is the combination of the parentheses and the explicit type argument that provokes the problem.

Comments
SUGGESTED FIX see http://sa.sfbay.sun.com/projects/langtools_data/7/6481655/
25-02-2008

EVALUATION This bug is somehow related to CR 6665356. When the parser see an open parenthesis it continue parsing the rest of the expression disabling type-arguments parsing. This is because otherwise there would be ambiguity between the this expression ( e < 5 && e > 0) //combination of binary operators < and > and this one: (Foo<String>) //generic cast expression For this reason javac disables parsing of type-arguments when parsing the content of a parenthesized expression. When a generic cast is ecnountered however, javac has to reconstruct the type-arguments information that has not been parsed yet. In this example we have that this expression is parsed succesfully: Util.<Object>cast(null); while this one is not (Util.<Object>cast(null)); The reason is that the parser is seeing an open parenthesis and, in order to avoid ambiguities, it disables type-argument parsing, as described above. In such a mode, there's no way to parse ".<Object>cast..." so the parser thinks that the end of the parenthesized expression is just after the '.', while it's not. Since generic method calls with explicit type-arguments are the only kind of expression such that the symbol '<' can follow an '.' , it is safe to temporary re-enable type-arguments parsing right after a '.' has been read (and re-disabling it after type-arguments --- if any --- have been parsed).
25-02-2008

EVALUATION A parser bug.
16-10-2006