JDK-4750181 : javac should use grammar from JLS sections 4, 6-10, 14, 15
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-09-19
  • 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
Relates :  
Relates :  
Description

Name: nt126004			Date: 09/19/2002


FULL PRODUCT VERSION :
java version "1.4.1-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b19)
Java HotSpot(TM) Client VM (build 1.4.1-rc-b19, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version
5.00.2195]

A DESCRIPTION OF THE PROBLEM :

The syntactic grammar is given by JLS as follows.

Primary:
    
PrimaryNoNewArray
    
ArrayCreationExpression

PrimaryNoNewArray:
    Literal
    Type .
class
    void . class
    this
    ClassName.this
    ( Expression )
    
ClassInstanceCreationExpression
    FieldAccess
    
MethodInvocation
    
ArrayAccess

ClassInstanceCreationExpression:
    new
ClassOrInterfaceType ( ArgumentListopt ) ClassBody opt
    Primary.new
Identifier ( ArgumentListopt ) ClassBody opt


It means the
following expression is an error.
(from Line 153 of java/util/logging/LogManager.java)

    manager.new RootLogger();


Also,

ArrayCreationExpression:
    new
PrimitiveType DimExprs Dimsopt
    new TypeName DimExprs Dimsopt
    new
PrimitiveType Dims ArrayInitializer
    new TypeName Dims
ArrayInitializer

ArrayAccess:
    ExpressionName [ Expression ]
    
PrimaryNoNewArray [ Expression ]

means the following expression is
error.  (from Bug Id 4321177)

    new char[] { 'B', 'u', 'g' }[i]

The
  state of 4321177 is "closed, not a bug," but it is a bug.  The
evaluation of 4321177 shows a grammar accepting the expression.  But,
the grammer is given in Chapter 18 of JLS.  Section 2.3 of JLS says

> The syntactic grammar for the Java programming language is given in
> Chapters 4, 6?]10, 14, and 15. This grammar has tokens defined by the
> lexical grammar as its terminal symbols. It defines a set of
> productions, starting from the goal symbol CompilationUnit (??7.3), that
> describe how sequences of tokens can form syntactically correct
> programs.

Only the grammer given in Chapters 4, 6?]10, 14, and 15
describes the syntactic correctness of programs.

I think we can have the following consensus:

(1) JLS gives two grammars.  One is defined in Chapter 4, 6-10, 14, and 
    15.  The other is defined in Chapter 18.
(2) The former rejects the expression "identifier.new ...", but the     
    latter accepts it.
(3) Either the former or the latter define the correct syntactic        
    grammar.  If the former is correct, every Java compiler (and Java   
    language tool) should reject the expression.  If the latter is      
    correct, every one should accept it in syntactic processes.
(4) For compatibility, it is important to clear which is correct.

> The grammar presented in chapter 18 of the JLS is an acceptable grammar.  

You think the latter is the better choice.  But, I think the former is  
the correct grammar for some reasons:

(1) The semantics of class instance creation expressions explicitly     
    demands the former.  In Section 15.9,
    > Class instance creation expressions have two forms:
    > - Unqualified class instance creation expressions begin with the      
    >   keyword new.
    > - Qualified class instance creation expressions begin with a Primary.
    Here, a Primary doesn't include a single identifier.
    
    And, in 15.9.1,
    > - If the class instance creation expression is an unqualified     
    >   class instance creation expression, ...
    > - Otherwise, the class instance creation expression is a qualified
    >   class instance creation expression.

(2) It is often said that the former is "the grammar" but the latter is 
    "a grammar."  In Chapter 1, "Chapter 2 describes grammars and the   
    notation used to present *the* lexical and syntactic grammars for   
    the language."  "Chapter 18 presents *a* syntactic grammar for the  
    language."  In Chapter 2, "This chapter describes the context-free  
    grammars used in this specification to define *the* lexical and     
    syntactic structure of a program."  In 2.3, "*The* syntactic grammar
    for the Java programming language is given in Chapters 4, 6-10, 14, 
    and 15."  In Chapter 18, "This chapter presents *a* grammar for the 
    Java programming language."

(3) Again, 
> The
>   state of 4321177 is "closed, not a bug," but it is a bug.  The
> evaluation of 4321177 shows a grammer accepting the expression.  But,
> the grammer is given in Chapter 18 of JLS.  Section 2.3 of JLS says
> 
> > The syntactic grammar for the Java programming language is given in
> > Chapters 4, 6?]10, 14, and 15. This grammar has tokens defined by the
> > lexical grammar as its terminal symbols. It defines a set of
> > productions, starting from the goal symbol CompilationUnit (??7.3), that
> > describe how sequences of tokens can form syntactically correct
> > programs.
> 
> Only the grammer given in Chapters 4, 6?]10, 14, and 15
> describes the syntactic correctness of programs.

(4) The latter is a only basis, so says nothing about the correct grammar.
> Chapter 18 states :

> The grammar presented piecemeal in the preceding chapters is much     
> better for exposition, but it is not ideally suited as a basis for a  
> parser. The grammar presented in this chapter is the basis for the    
> reference implementation. 

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile java/util/logging/LogManager.java and the following
ArrayBug.

EXPECTED VERSUS ACTUAL BEHAVIOR :
javac rejects the errors with error messages.
(Or, an update of JLS to
accept the expressions.  It will be better for Java 1.5)


ERROR MESSAGES/STACK TRACES THAT OCCUR :
No message.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
(1) java/util/logging/LogManager.java  (1.20 01/12/03)

(2) (from Bug Id 4321177)
public class ArrayBug {
    public static void main(String args[]) {
        for (int i = 0; i < 3; i++) {
            System.out.print(new char[] { 'B', 'u', 'g' }[i]);
        }
        System.out.println(new char[] { 'O', 'K' }.length);
    }
}

---------- END SOURCE ----------
(Review ID: 164525) 
======================================================================

Comments
EVALUATION This CR mainly concerns old discrepancies (regarding the use of identifiers) between the expository grammar in 15.9 and the reference grammar in 18.1. These were fixed in JLS 3ed. However, the points about which grammar is definitive are well taken. JLS 2.3 should note that _a_ syntactic grammar is given in chs.4,6-10,14,15 but that ch.18 presents another syntactic grammar for the _same_ language.
24-04-2007

EVALUATION Verified as follows: Line 153 of java/util/logging/LogManager.java is manager.rootLogger = manager.new RootLogger(); Which is parsed as follows: BlockStatement apply 14.2 BlockStatement: Statement Statement apply 14.5 Statement: StatementWithoutTrailingSubstatement StatementWithoutTrailingSubstatement apply 14.5 StatementWithoutTrailingSubstatement: ExpressionStatement ExpressionStatement apply 14.8 ExpressionStatement: StatementExpression ; StatementExpression ; apply 14.8 StatementExpression: Assignment Assignment ; apply 15.26 Assignment: LeftHandSide AssignmentOperator AssignmentExpression LeftHandSide AssignmentOperator AssignmentExpression ; apply 15.26 LeftHandSide: ExpressionName ExpressionName AssignmentOperator AssignmentExpression ; apply 6.2 ExpressionName: AmbiguousName . Identifier AmbiguousName . Identifier AssignmentOperator AssignmentExpression ; apply 6.2 AmbiguousName: Identifier Identifier . Identifier AssignmentOperator AssignmentExpression ; apply 15.26 AssignmentOperator: = Identifier . Identifier = AssignmentExpression ; apply 15.26 AssignmentExpression: ConditionalExpression Identifier . Identifier = ConditionalExpression ; apply 15.25 ConditionalExpression: ConditionalOrExpression apply 15.24 ConditionalOrExpression: ConditionalAndExpression apply 15.23 ConditionalAndExpression: InclusiveOrExpression apply 15.22 InclusiveOrExpression: ExclusiveOrExpression apply 15.22 ExclusiveOrExpression: AndExpression apply 15.22 AndExpression: EqualityExpression apply 15.21 EqualityExpression: RelationalExpression apply 15.20 RelationalExpression: ShiftExpression apply 15.19 ShiftExpression: AdditiveExpression apply 15.18 AdditiveExpression: MultiplicativeExpression apply 15.17 MultiplicativeExpression: UnaryExpression apply 15.15 UnaryExpression: UnaryExpressionNotPlusMinus apply 15.15 UnaryExpressionNotPlusMinus: PostfixExpression apply 15.14 PostfixExpression:: Primary apply 15.8 Primary: PrimaryNoNewArray apply 15.8 PrimaryNoNewArray: ClassInstanceCreationExpression apply 15.9 ClassInstanceCreationExpression: Primary.new Identifier ( ArgumentListopt ) ClassBodyopt Identifier . Identifier = Primary.new Identifier ( ArgumentListopt ) ClassBodyopt At this point, there is no way to accept an Identifier as a Primary, so there is a syntax error. As this is not likely the intended result, I am reclassifying this as a spec bug. ###@###.### 2002-09-19
19-09-2002