Bug ID: JDK-6481655 Parser confused by combination of parens and explicit type args

Versions (Unresolved/Resolved/Fixed)

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

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.

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

Duplicate :	JDK-7019649 - Syntax error for ternary operator with a generic method call as second result
Duplicate :	JDK-6998697 - boolean expression deemed illegal - but only inside of an assertion
Relates :	JDK-6318240 - Creation of array of inner class of an enclosing wildcard type doesn't work
Relates :	JDK-6665356 - Cast not allowed when both qualifying type and inner class are parameterized