openbook.tools.parser.JavaParser
A Java 1.5 grammar for ANTLR v3 derived from the spec This is a very close representation of the spec; the changes are comestic (remove left recursion) and also fixes (the spec isn't exactly perfect). I have run this on the 1.4.2 source and some nasty looking enums from 1.5, but have not really tested for 1.5 compatibility. I built this with: java -Xmx100M org.antlr.Tool java.g and got two errors that are ok (for now): java.g:691:9: Decision can match input such as "'0'..'9'{'E', 'e'}{'+', '-'}'0'..'9'{'D', 'F', 'd', 'f'}" using multiple alternatives: 3, 4 As a result, alternative(s) 4 were disabled for that input java.g:734:35: Decision can match input such as "{'$', 'A'..'Z', '_', 'a'..'z', '\u00C0'..'\u00D6', '\u00D8'..'\u00F6', '\u00F8'..'\u1FFF', '\u3040'..'\u318F', '\u3300'..'\u337F', '\u3400'..'\u3D2D', '\u4E00'..'\u9FFF', '\uF900'..'\uFAFF'}" using multiple alternatives: 1, 2 As a result, alternative(s) 2 were disabled for that input You can turn enum on/off as a keyword :) Version 1.0 -- initial release July 5, 2006 (requires 3.0b2 or higher) Primary author: Terence Parr, July 2006 Version 1.0.1 -- corrections by Koen Vanderkimpen & Marko van Dooren, October 25, 2006; fixed normalInterfaceDeclaration: now uses typeParameters instead of typeParameter (according to JLS, 3rd edition) fixed castExpression: no longer allows expression next to type (according to semantics in JLS, in contrast with syntax in JLS) Version 1.0.2 -- Terence Parr, Nov 27, 2006 java spec I built this from had some bizarre for-loop control. Looked weird and so I looked elsewhere...Yep, it's messed up. simplified. Version 1.0.3 -- Chris Hogue, Feb 26, 2007 Factored out an annotationName rule and used it in the annotation rule. Not sure why, but typeName wasn't recognizing references to inner annotations (e.g. @InterfaceName.InnerAnnotation()) Factored out the elementValue section of an annotation reference. Created elementValuePair and elementValuePairs rules, then used them in the annotation rule. Allows it to recognize annotation references with multiple, comma separated attributes. Updated elementValueArrayInitializer so that it allows multiple elements. (It was only allowing 0 or 1 element). Updated localVariableDeclaration to allow annotations. Interestingly the JLS doesn't appear to indicate this is legal, but it does work as of at least JDK 1.5.0_06. Moved the Identifier portion of annotationTypeElementRest to annotationMethodRest. Because annotationConstantRest already references variableDeclarator which has the Identifier portion in it, the parser would fail on constants in annotation definitions because it expected two identifiers. Added optional trailing ';' to the alternatives in annotationTypeElementRest. Wouldn't handle an inner interface that has a trailing ';'. Swapped the expression and type rule reference order in castExpression to make it check for genericized casts first. It was failing to recognize a statement like "Class TYPE = (Class)...;" because it was seeing 'Class'. Changed createdName to use typeArguments instead of nonWildcardTypeArguments. Again, JLS doesn't seem to allow this, but java.lang.Class has an example of of this construct. Changed the 'this' alternative in primary to allow 'identifierSuffix' rather than just 'arguments'. The case it couldn't handle was a call to an explicit generic method invocation (e.g. this.doSomething()). Using identifierSuffix may be overly aggressive--perhaps should create a more constrained thisSuffix rule? Version 1.0.4 -- Hiroaki Nakamura, May 3, 2007 Fixed formalParameterDecls, localVariableDeclaration, forInit, and forVarControl to use variableModifier* not 'final'? (annotation)? Version 1.0.5 -- Terence, June 21, 2007 --a[i].foo didn't work. Fixed unaryExpression Version 1.0.6 -- John Ridgway, March 17, 2008 Made "assert" a switchable keyword like "enum". Fixed compilationUnit to disallow "annotation importDeclaration ...". Changed "Identifier ('.' Identifier)*" to "qualifiedName" in more places. Changed modifier* and/or variableModifier* to classOrInterfaceModifiers, modifiers or variableModifiers, as appropriate. Renamed "bound" to "typeBound" to better match language in the JLS. Added "memberDeclaration" which rewrites to methodDeclaration or fieldDeclaration and pulled type into memberDeclaration. So we parse type and then move on to decide whether we're dealing with a field or a method. Modified "constructorDeclaration" to use "constructorBody" instead of "methodBody". constructorBody starts with explicitConstructorInvocation, then goes on to blockStatement*. Pulling explicitConstructorInvocation out of expressions allowed me to simplify "primary". Changed variableDeclarator to simplify it. Changed type to use classOrInterfaceType, thus simplifying it; of course I then had to add classOrInterfaceType, but it is used in several places. Fixed annotations, old version allowed "@X(y,z)", which is illegal. Added optional comma to end of "elementValueArrayInitializer"; as per JLS. Changed annotationTypeElementRest to use normalClassDeclaration and normalInterfaceDeclaration rather than classDeclaration and interfaceDeclaration, thus getting rid of a couple of grammar ambiguities. Split localVariableDeclaration into localVariableDeclarationStatement (includes the terminating semi-colon) and localVariableDeclaration. This allowed me to use localVariableDeclaration in "forInit" clauses, simplifying them. Changed switchBlockStatementGroup to use multiple labels. This adds an ambiguity, but if one uses appropriately greedy parsing it yields the parse that is closest to the meaning of the switch statement. Renamed "forVarControl" to "enhancedForControl" -- JLS language. Added semantic predicates to test for shift operations rather than other things. Thus, for instance, the string "< <" will never be treated as a left-shift operator. In "creator" we rule out "nonWildcardTypeArguments" on arrayCreation, which are illegal. Moved "nonWildcardTypeArguments into innerCreator. Removed 'super' superSuffix from explicitGenericInvocation, since that is only used in explicitConstructorInvocation at the beginning of a constructorBody. (This is part of the simplification of expressions mentioned earlier.) Simplified primary (got rid of those things that are only used in explicitConstructorInvocation). Lexer -- removed "Exponent?" from FloatingPointLiteral choice 4, since it led to an ambiguity. This grammar successfully parses every .java file in the JDK 1.5 source tree (excluding those whose file names include '-', which are not valid Java compilation units). Known remaining problems: "Letter" and "JavaIDDigit" are wrong. The actual specification of "Letter" should be "a character for which the method Character.isJavaIdentifierStart(int) returns true." A "Java letter-or-digit is a character for which the method Character.isJavaIdentifierPart(int) returns true."