United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6481655 Parser confused by combination of parens and explicit type args
JDK-6481655 : Parser confused by combination of parens and explicit type args

Details
Type:
Bug
Submit Date:
2006-10-13
Status:
Closed
Updated Date:
2011-05-18
Project Name:
JDK
Resolved Date:
2011-05-18
Component:
tools
OS:
linux,generic,windows_7
Sub-Component:
javac
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
6,6u23,7
Fixed Versions:

Related Reports
Duplicate:
Duplicate:
Relates:
Relates:

Sub Tasks

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
EVALUATION

A parser bug.
                                     
2006-10-16
SUGGESTED FIX

see http://sa.sfbay.sun.com/projects/langtools_data/7/6481655/
                                     
2008-02-25
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).
                                     
2008-02-25



Hardware and Software, Engineered to Work Together