* JSR 308

1. Some final spec errata (ArrayType, AnnotationTypeElementDeclaration)

See http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2014-February/000181.html

2. The grammar doesn't define any production for the following expression: char[].class

This is a side-effect of determining that a class literal is not a "type use". It led to the following observation in 308's Public Review: "For a class literal expression, JLS7's grammar uses Type before .class, and 15.8.2 requires a semantic error if a parameterized type or type variable is used. However, javac assumes TypeName before .class, as evidenced by the fact that a syntax error occurs if a non-ground type is used. JLS8 should follow javac by defining a class literal expression as TypeName {[]}.class. JLS8 still needs a semantic error to prohibit type variables, which are syntactically valid before .class."

To compensate, it is necessary to add '(NumericType | boolean) {[]} . class' to PrimaryNoNewArray. (Can't use PrimitiveType since it allows annotations, which are verboten in a class literal.)

3. The grammar doesn't define any production for the following expression: new java.security.Permissions()

This is a side-effect of removing TypeDeclSpecifier in 4.3, as it interacted poorly with type annotations. The JSR 308 Public Review noted: "TypeDeclSpecifier is one of the more obscure nonterminals in the The Java Language Specification. It is used in only a handful of situations: the extends and implements clauses of a class declaration (8.1.4, 8.1.5), the extends clause of an interface declaration (9.1.3), and the syntax of a class instance creation expression (15.9). The reason for its use is to prohibit wildcard type arguments (though 9.1.3 actually fails to do so), but this can be achieved equally well without a dedicated non-terminal."

'extends' and 'implements' clauses rely on ClassType and InterfaceType, which allow qualified type names, but ClassInstanceCreationExpression [without TypeDeclSpecifier] fails to allow qualified type names. The fix is to add {{Annotation} Identifier} in the three CICE alternatives. (There's a semantic constraint in 9.7.4 that prohibits type annotations on package names, but that's not of concern to the grammar.)

4. JVMS8 4.7.20 forgets one of the JLS type contexts:

"The kinds of target in Table 4.7.20-A and Table 4.7.20-B correspond to the type contexts in JLS §4.11.... while target_type values 0x43-0x4B correspond to type contexts 11-15."

This should be:

"... correspond to type contexts 11-16."

5. JVMS8 Table 4.7.20-A. Interpretation of target_type values (Part 1) says for supertype_target:

"type in extends clause of class or interface declaration (including the direct superclass of an anonymous class declaration), or in implements clause of interface declaration"

This should be:

"type in extends _or implements_ clause of class declaration (including the direct superclass _or direct superinterface_ of an anonymous class declaration), or in _extends_ clause of interface declaration"


* JSR 335

1. JLS8 6.5.1 forgets to classify the type of a lambda expression's formal parameter:

"The type in a formal parameter declaration of a method or constructor (§8.4.1, §8.8.1, §9.4)"

This should follow 4.11 by saying:

"The type in a formal parameter declaration of a method, constructor, or lambda expression (§8.4.1, §8.8.1, §9.4, §15.27.1)"

2. The grammar doesn't define any production for the following expression:

(null == targetRef) ? Objects::isNull : object -> targetRef.equals(object)

Specifically, the right hand side of a ConditionalExpression is ConditionalExpression, not Expression (the latter would allow a LambdaExpression to appear there). The expression appears in java/util/function/Predicate.java.

This is a side-effect of a late decision in SE 8 to make LambdaExpression be an Expression, where previously it had been a PrimaryExpression. The conservative course of action is simply to add 'ConditionalOrExpression ? Expression : LambdaExpression' as an alternative for ConditionalExpression. This mirrors the treatment of lambdas in cast expressions (15.16).