JDK-6442525 : Syntax specification (section 18) is inconsistent with other sections
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,solaris_8
  • CPU: generic,x86
  • Submitted: 2006-06-23
  • Updated: 2014-02-26
  • Resolved: 2011-07-21
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 rcFixed
Related Reports
Duplicate :  
JDK-5014480 - javac incorrectly accepts obsolescent array return type on annotation elements
Relates :  
JDK-6923696 - Allow mixed array brackets for enhanced for loop's variable
Relates :  
JDK-6505167 - Annotations syntax error in JLS 9.7
Relates :  
JDK-6998735 - Variable arity parameter type involving arrays
Relates :  
JDK-4750181 - javac should use grammar from JLS sections 4, 6-10, 14, 15
Description
A DESCRIPTION OF THE PROBLEM :
The syntax specification in section 18.1 is inconsistent with the fragements given in other sections of the JLS. An example is 'TypeArgument', which allows 'BasicType' to be used in the specification. However the same rule in section 4.5.1 uses 'ReferenceType', which is not even part of the syntax given in section 18.1. Also note that the definition given in 4.5.1 accepts a different language than the one given in 18.1.

I think it is unclear to use different grammars throughout the document. It makes it impossible to use section 18.1 as a reference while reading the rest of the document. For the 'ReferenceType' example, the reader has to skip to section 4.3 to find the syntax of 'ReferenceType'.

Section 18.1 also contains a typo in the rule for 'Expression': the optional 'AssignmentOperator Expression1' is closed twice.


REPRODUCIBILITY :
This bug can be reproduced always.
Comments
EVALUATION This is the master bug for errors in the Java grammar. * 18.1 does not permit the obsolescent array syntax in a method declaration of an annotation type. As per 5014480, it should. AnnotationMethodRest: '(' ')' {'['']'} [DefaultValue] 9.6 should permit the old syntax too: AnnotationTypeElementDeclaration: AbstractMethodModifiersopt Type Identifier ( ) Dimsopt DefaultValueopt ; * 18.1 and 14.14.2 do not permit the obsolesent array syntax for the enhanced for loop's variable (6923696). 14.14.2 should say: EnhancedForStatement: for (FormalParameter : Expression) Statement Happily, using FormalParameter here aligns with the text a few lines below: "The scope of a local variable declared in the FormalParameter part of an enhanced for...". Note that the definition of FormalParameter in 8.4.1 is corrected separately. Unfortunately, the grammar for the enhanced for loop in 18 cannot use FormalParameter because of left-factoring. In fact, 18 is tricky to update. A normal variable declaration (VariableDeclarator), including one in the init of a normal for loop, allows [] after the Identifier and allows a further "= ...". There is no such grammatical construct as a variable declaration which allows [] after the Identifier without allowing further assignment - but that's the construct we need for the enhanced for loop. We would like to say: ForVarControl: [final] [Annotations] Type ***VariableDeclaratorId*** ForVarControlRest but must watch for ambiguity: VariableDeclaratorId may end with [] (after the Identifier) and ForVarControlRest allows VariableDeclaratorsRest which may start with []. So we also need: ForVarControlRest: ['=' VariableInitializer] { ',' VariableDeclarator } ';' [Expression] ';' [ForUpdate] ':' Expression * 18.1 has an incorrect CatchClause wrong because FormalParameter does not exist in 18: catch '(' FormalParameter ')' Block A solitary formal parameter enclosed by parentheses is not needed elsewhere in the grammar, hence no FormalParameter; only FormalParameters. Let's copy from FormalParameterDecls, noting that it's impossible to catch an array, so we should use Identifier rather than VariableDeclaratorId: catch '(' [final] [Annotations] Type Identifier ')' Block 8.4.1 and 14.20 should use the following definition of FormalParameter: FormalParameter: VariableModifiers_opt Type VariableDeclaratorId 8.4.1 should also redefine LastFormalParameter as per 6998735. * 'new Foo<?>()' is illegal (wildcards cannot appear in an rvalue, as stated in 15.9) but 'new Foo<?>[]' is legal. The former is syntactically permitted in 15.9 but the grammar there is not definitive. It's not permitted in 18.1, which in itself is good, but 18.1 is too tight and the latter is not permitted. The fact that the latter is permitted in 15.10 is irrelevant since the grammar there is not definitive. Creator should be factored so that intelligence about parameterized type names lives in the productions for array v. class creation: Creator: [NonWildcardTypeArguments] Identifier (ArrayCreatorRest | ClassCreatorRest) ArrayCreatorRest: [UnboundedWildcardTypeArguments] '[' ( ']'{'[]'}ArrayInitializer | Expression']'{'['Expression']'}{'[]'} ) UnboundedWildcardTypeArguments: '<' (Type|'?') { ',' (Type|'?') } '>' ClassCreatorRest: [NonWildcardTypeArguments] { '.' Identifier [NonWildcardTypeArguments] } Arguments [ClassBody] * 18.1 does not permit primitive array types: Type: Identifier [TypeArguments] { '.' Identifier [TypeArguments]} {'[]'} BasicType * 18.1 defines TypeArgument incorrectly, e.g. '? extends int' is legal. Correct are ActualTypeArgument and Wildcard from 4.5.1. They use ReferenceType, which is in 4.3 but not 18.1. * 18.1 incorrectly permits only one label per BlockStatement in a switch, and should be: SwitchBlockStatementGroup: SwitchLabels BlockStatements SwitchLabels: SwitchLabel { SwitchLabel } * 18.1 should follow 14.4 in allowing annotations on local variables, and should introduce VariableModifier to do so: LocalVariableDeclarationStatement: {VariableModifier} Type VariableDeclarators ';' VariableModifier: 'final' Annotation FormalParameterDecls and ForVarControl should start with {VariableModifier} rather than [final][Annotations]. 14.4 should make VariableModifier _opt and repeat the definition of VariableModifier from 8.4.1. * 18.1 should use the following definitions for consistency with 9.7 (see 6505167): Annotation: @TypeName [ ( [ AnnotationElement ] ) ] TypeName: Identifier AnnotationElement: ElementValue ElementValuePairs ElementValuePairs: ElementValuePair {, ElementValuePair} ElementValuePair: Identifer = ElementValue ElementValues: ElementValue {, ElementValue} * 18.1 and 8.9 have EnumConstant wrong and should be: EnumConstant: Annotations_opt Identifier Arguments_opt ClassBody_opt * 18.1 fails to define ForUpdate, which should be the same as ForInit. * AnnotationTypeDeclaration should not have 'interface' in italics. * FormalParameterDecls has a trailing ] * MethodOrFieldRest should have a ; after VariableDeclaratorsRest * 18.1 has a plain bug in AnnotationConstantRest. Its use of VariableDeclarators means two Identifiers are accepted for an AnnotationTypeElementRest, e.g. int x y = 5; It should be: AnnotationConstantRest: VariableDeclaratorsRest * AnnotationTypeElementRest has redundant EnumDeclaration and AnnotationTypeDeclaration productions. * Expression2Rest has an errant Expression3 before instanceof. It should be: {InfixOp Expression3} instanceof Type * Expression2 has a space between its LHS nonterminal and its colon. * BlockStatement has a space between its LHS nonterminal and its colon. * Rule Selector has its LHS nonterminal repeated.
24-10-2006