Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7080366

Grammar bugs in JLS7

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not an Issue
    • Icon: P4 P4
    • 8
    • 8
    • specification
    • None
    • generic
    • generic

      1) Minor problems in chapters 2-15, remedied in JLS7 renderings post-2011

      - MarkerAnnotation in JLS7 9.7.2 and SingleElementAnnotation in JLS7 9.7.3
        both use Identifier when TypeName would be proper (see 9.7.1).

      - BlockStatement in JLS7 14.2 inadvertently allowed ClassOrInterfaceDeclaration.
        Should be just ClassDeclaration, per JLS3 14.2.

      - (Due to Markus K)
        AnnotationTypeElementDeclaration in JLS7 9.6.1 (and 18) includes ClassDeclaration,
        InterfaceDeclaration, EnumDeclaration, and AnnotationTypeDeclaration, but the
        last two productions are included in the first two productions. EnumDeclaration
        and AnnotationTypeDeclaration should be removed. This aligns
        AnnotationTypeElementDeclaration with InterfaceMemberDeclaration and
        ClassMemberDeclaration.

      - Not part of the grammar, but a formatting error in Table 4.1 "Floating-point value set parameters".
        The K parameter for double has an erroneous >=. It should just be 11, not >=11.
        The K parameter for double-extended-component should be >=15, not 15.


      2) Minor problems in chapter 18, remedied in JLS7 renderings post-July 2011

      /.../ indicates italic font, i.e. BNF conventions.

      - (Due to Bill F)
        AnnotationTypeBody uses /{/ and /}/ (i.e. italicized { } terminals) around
        [AnnotationTypeElementDeclarations] but it should use literal curly brackets.

        The BNF convention x | y should have parentheses, as that is how it's always used.
        The | character should be italized as it is a BNF convention: /(/ x /|/ y /)/
        (Turns out it is hard to find a suitable symbol.)

      - Expression3 introduces casts, and the brackets around Expression|Type should be tokens, not BNF conventions:

        Expression3: ( Expression /|/ Type ) Expression3

      - ArrayCreatorRest has an unnecessary trailing ] and should be presented as:

        ArrayCreatorRest: [ /(/
                                ] /{/[]/}/ ArrayInitializer
                            /|/
                                Expression ] /{/[ Expression ]/}/ /{/[]/}/
                            /)/

      - CatchType should use QualifiedIdentifier, not Identifier:

        CatchType: QualifiedIdentifier { *|* QualifiedIdentifier }


      3) Major problems in chapter 18, to be remedied in JLS8

      - IdentifierSuffix: [ /(/ /{/ [] /}/ . class /|/ Expression /)/ ]

        is erroneous. It should revert to the JLS3 production (better spaced out) :

        IdentifierSuffix: [ /(/
                                ] /{/[]/}/ . class
                            /|/
                                Expression ]
                            /)/

      - FormalParameters has always had a different RHS in ch.18 than in 8.4.1. This is confusing. Duplication of
        non-terminals between chs.1-17 and ch.18 is also undesirable, as is introducing further names
        (e.g. FormalParameterSection) for what is an obvious concept. Since FormalParameters is only used in five
        closely related productions (MethodDeclaratorRest, VoidMethodDeclaratorRest, ConstructorDeclaratorRest,
        InterfaceMethodDeclaratorRest, VoidInterfaceMethodDeclaratorRest), I propose to remove FormalParameters
        from ch.18 and inline its RHS:

        MethodDeclaratorRest:
          ( /[/FormalParameterDecls/]/ ) /{/[]/}/ /[/throws QualifiedIdentifierList/]/ /(/Block /|/ ;/)/

      - (Due to Thomas W)
        The intent in ch.9 of ElementValueArrayInitializer and in ch.10 of ArrayInitializer is that
        a single comma is legal as the only content of initializer brackets.
        The ch.18 version of ArrayInitializer does not conform, and should become:

        { [ VariableInitializer { , VariableInitializer } ] [,] }

        The ch.18 version of ElementValueArrayInitializer does conform, but uses an
        unnecessary intermediate ElementValues production. We can simply inline the
        RHS of ElementValues to achieve a pleasing consistency:

        { [ ElementValue { , ElementValue } ] [,] }

      - (Due to Robert S)
        JLS7 4.5.1 defines TypeArgument as ReferenceType or Wildcard, where ReferenceType is defined by 4.3
        to include ArrayType. This is correct, since for example List<? extends Object[][]> is legal.
        TypeArgument in JLS7 18 also relies on ReferenceType, but 18's ReferenceType does not include array types,
        so TypeArgument in 18 needs to add the [] type constructor explicitly.

        Furthermore, a wildcard type argument's bound can be an array type of primitives, e.g. List<? extends int[]>.
        So we can allow 18's BasicType to appear after extends/super, provided it has at least one [] type constructor
        (since List<? extends int> is not legal).

        TypeArgument:
          ReferenceType {[]}
          ? [ ( extends | super ) ( BasicType [] {[]} | ReferenceType {[]} ) ]

        Contrast with the bound of a type parameter, which is forbidden from being an array type by both JLS7 4.4
        (uses TypeVariable and ClassOrInterfaceType) and JLS7 18 (uses ReferenceType).

            abuckley Alex Buckley
            abuckley Alex Buckley
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: