Find JSRs
Submit this Search

Ad Banner

Maintenance Review of JSR 901 (JavaTM Language Specification) for Java SE 7

Last updated 2011-03-18 by Alex Buckley

The clarifications and amendments below are proposed to the Java Language Specification, Third Edition.

The complete amended specification is the Java Language Specification, Java SE 7 Edition. (The next edition of the Java Virtual Machine Specification will also be known as the Java SE 7 Edition.)

As features are added to the Java language, the Java Language Specification grows longer and more complex. Features must be introduced, specified, exemplified, discussed, and interwoven with existing features. The Technology Compatibility Kit for the Java language must be updated too, as per the Java Community Process. To maintain readability and to support testability, it is desirable for the Java Language Specification to strongly differentiate normative material from informative material. For example, the compile-time errors possible for a field declaration are normative, but the conventional order of modifiers in a field declaration is informative. As another example, the rules of definite assignment are normative but an extended discussion of source code to show subtleties of the rules is informative.

As a result, there are two versions available of the Java Language Specification, Java SE 7 Edition:

  • The normative version (382 pages) contains only the syntax, definitions, and rules of the Java programming language, without examples or discussion.
  • The full version (586 pages) is the text of the normative version plus inline examples and discussion, as was the style in the Third Edition.

In both versions, red text is new in the Java SE 7 Edition; blue text is changed with respect to the Third Edition.

Clarifications and Amendments to the Java Language Specification, Third Edition

Organization of the Specification

Normative material

Cross-cutting rules concerning variable declarations have been centralized, rather than continuing to be spread throughout the Specification wherever a declaration of some kind of variable was discussed. Namely, the rules for scope, shadowing, mixed array notation, and exception checking are centralized in 6.3, 6.4.1, 10.2, and 11.2.3, and moreover are not duplicated in other sections. Informative text in other sections refers to the central definitions. Type Argument Containment and Heap Pollution have been incorporated into their immediately preceding sections.

5.5 Casting Conversion has been split into four sections for clarity.

7.4.4 Scope of a Package Declaration has been removed (in line with the centralization theme discussed later), and its material incorporated into 6.3 Scope and 6.4.1 Shadowing.

7.5.5 Automatic Imports has been removed, and its material incorporated into 7.3 Compilation Units (which it essentially duplicated already).

8.9 Enums has been given two subsections for clarity.

9.1.5 Access to Interface Member Names has been removed, since its point about implicitly public members is duplicated in 9.3, 9.4, and 9.5.

9.6 Annotation Types has been given two additional subsections for clarity. This has resulted in 9.6.1 Predefined Annotation Types shifting down to 9.6.3.

11.3.1 Exceptions are Precise has been incorporated into 11.3 Run-Time Handling of an Exception. 11.3.2 Handling Asynchronous Exceptions has been moved to 11.1. 11.5 The Exception Hierarchy mainly mirrored observations on exception types in 11.1 and 11.2, so has been removed and its material incorporated into those sections. String Conversion has been moved to 5.1.11.

17.8 Wait Sets and Notification and 17.9 Sleep and Yield have been moved to 17.2 and 17.3 respectively. (See below for the original 17.3.)

Informative material

It is desirable to keep section numbering consistent between the normative and full versions of the Specification, which means that example-only sections are not possible. As a result, example-only sections have been removed. Most were the last section at their level, so this one-time change has not affected broader section numbering (except in minor ways in chapters 10, 11, and 17). The examples have been added as informative material in closely related sections. The removed sections are:

6.6.3 An Example of Access Control
6.6.4 Example: Access to public and Non-public Classes
6.6.5 Example: Default-Access Fields, Methods, and Constructors
6.6.6 Example: public Fields, Methods, and Constructors
6.6.7 Example: protected Fields, Methods, and Constructors
6.6.8 Example: private Fields, Methods, and Constructors
7.5.6 A Strange Example
8.2.1 Examples of Inheritance
8.3.3 Examples of Field Declarations
8.4.10 Examples of Method Declarations
9.3.2 Examples of Field Declarations
9.4.3 Examples of Abstract Method Declarations
10.5 Arrays: A Simple Example
11.4 An Example of Exceptions Examples Example: Overloading Ambiguity Example: Return Type Not Considered Example: Compile-Time Resolution
15.13.2 Examples: Array Access Evaluation Order Examples of String Concatenation
17.3 Incorrectly Synchronized Programs Exhibit Surprising Behaviors

6.4 Members and Inheritance appeared normative, but in fact merely duplicated many normative statements of chapters 7-10, as well as re-describing properties of packages and reference types implied by those chapters. A small amount of informative material from 6.4 has been incorporated into 7.1, 8.2, and 9.2 to improve readability; the rest of 6.4 has been deleted. 6.4 now contains the definitions of shadowing and obscuring formerly found in 6.3.1 and 6.3.2.

6.8 Naming Conventions and 7.7 Unique Package Names were entirely informative, and have been incorporated as informative material into 6.1 Declarations and 6.4 Shadowing and Obscuring. Package Annotations was mainly informative, so has been removed and all its material incorporated into 7.4.1 Named Packages.

Exploiting the ability to give more discussion without cluttering the normative version of the Specification, there are new discussions in 4.8 Raw Types, 6.6 Access Control, and 15.8 Primary Expressions that clarify some long-held principles of the Java language.

Proposed changes, by chapter

Defects in the Java Language Specification are tracked as bugs in the java:specification category of the Java Bug Database. The list below gives the ID and synopsis for each bug whose evaluation proposes a clarification or amendment to the Java Language Specification, Third Edition.

Some defects in the Java Language Specification are related to defects in javac, the Reference Implementation of a compiler for the Java language. Bugs for compiler defects are tracked in the java:compiler category. If a specification bug is strongly related to a compiler bug, then the compiler bug is listed below the specification bug for completeness, indented and entirely surrounded by [ ].

Occasionally, a compiler bug proposes a change in the Java Language Specification and it is more convenient to record the change in the compiler bug rather than creating a separate specification bug. Consequently, a few specification bugs below are actually in the java:compiler category, and are identified by [ ] around the synopsis.

In addition to the bugs below, 7029127 Public comments on JLS3 records proposed changes due to comments sent between 2006 and 2011 from members of the public to the Maintenance Lead of JSR 901 regarding the Java Languge Specification.

Lexical Structure
4685937 JLS3 3.10.2 has misleading information on largest/smallest floating-point literals
6869735 Re-specify scope of type parameters
7002097 Scope of a class or interface's type parameter
6193815 No cycles in subtyping of type variables
6674900 Clarify difference between a Type Variable and a Type Parameter
6776599 [Accept explicit type arguments on call of nongeneric method]
4922142 generic enclosing type in cast: allowed?
6558462 Nested classes and reified types
6806876 [ClassCastException occurs in assignment expressions without any heap pollutions]
6651719 [Compiler crashes during forward reference of TypeParameter]
6557279 Tweak provable distinctness
6508599 No unchecked conversion for array types
6526446 Fixes to JLS5.5 Casting Conversion
 [6790039 overhaul cast-conversion (umbrella)]
6558543 Widening reference conversion followed by unboxing isn't allowed
6558557 Overhaul specification of unchecked casts
6586958 Boxing conversion for the null type is unspecified
6888770 conditional operator with autoboxing spec bug
6730568 Type erasure affects return types + type parameters
6493167 Ban use of static nested parameterized classes
 [6486430 Compiler fails to reject access to static member in parameterized type]
6865515 Unclear rule for qualified access to member types
4420532 Current compilation unit is observable, hence its packages too
6536999 JLS3 chapter 7 Packages has several typos and inaccuracy
6470991 Package statement affected by imports
6975015 Stricter prohibition against import from unnamed package
6424261 Description of "override" in JLS 3 section 6.4.3 is misleading
4713248 spurious constraint re: anon classes+enclosing instances
6748088 Abstract classes and interfaces should inherit methods similarly
 [6294779 Problem with interface inheritance and covariant return types]
6998735 Variable arity parameter type involving arrays
7004835 Different handling for final in constructor
4626788 implicit use of this before super() should be disallowed
6708938 Synthetic super-constructor call should never use 'this' as qual
 [6541876 "Enclosing Instance" error new in 1.6]
6182950 [methods clash algorithm should not depend on return type]
6487370 [javac warning with override-equivalent inherited methods]
6510286 [Wording of javac error for inner classes]
6505167 Annotations syntax error in JLS 9.7
5008260 @Override should be generalized from 'superclass' to 'supertype'
 [6399361 CONFORMANCE: @Override specification and compiler inconsistent]
6554157 JLS uncaught exception handling documentation needs updating
6720843 Clarify that the throw statement can take null
6653965 'throw' statement over-simplifies when 'throws' clause is needed
4948126 Unreachable code in catch(Exception/RuntimeException) blocks
6412514 Message "" have to be reported
 [6558548 The compiler needs to be aligned with clarified specification of throws]
Compiling, Linking, and Compatibility
6519118 Classes are compiled but java.lang.AbstractMethodError is thrown
6254762 Initializing a class requires acquiring lock on its class object
6888125 Class initialization spec must allow static finals to be assigned early
4644624 implicitly declared interface members do not appear in classfile
4402219 Class.newInstance() versus inner classes
6520153 values/valueof methods of enum should be marked as SYNTHETIC
6302175 Second argument of assert not always converted to a String
6394986 assert must cause the enclosing top level class to be initialized?
6690688 Enhanced-for-loop translation in JLS 14.14.2 is not type-safe
6923689 Enhanced for loop with unsafe generics is incorrectly desugared
6923696 Allow mixed array brackets for enhanced for loop's variable
6906550 JLS3 14.17 is lax about enclosing method of a return statement
6225454 Magic scope rule for enums
4407262 ArrayInitializers and OutOfMemoryError
7122416 super field access and accessibility
6260924 The Primary of a method invocation must be a reference type
7013170 varargs: accessibility check missing from JLS 15.12.{2,4}
4721499 can a final variable be the operand of ++? --? +=?
6371674 Inferred types' bounds should help infer type variables
 [6369605 type-inference problems w/underconstrained t-vars & fbounds]
6369608 Inferred types not substituted in bounds of type variables
 [6730476 t-vars inferred in not substituted into formals]
6640435 inference: propagate >> constraints to help uninferred t-vars
 [6638712 type-inference causes selection of inapplicable method]
 [6650759 type-inference should propagate constraints]
 [6278587 Compiler fails to infer type for under-constrained t-vars]
6785114 Return type inference ( doesn't work with autoboxing
 [6995200 JDK 7 compiler crashes when type-variable is inferred from expected primitive type]
6568599 inference: Failure of inference due to lci definition
Reachability and Definite Assignment
4088988 Not detecting unreachable (exit via break w/intervening finally)
4642762 When can a statement complete normally? (break&cont v. finally)
4770552 Conflict in DA spec for local classes
6499725 "V is definitely unassigned after e2" is ambiguous for try statements
7006251 Reachability/Def.assign when enum constants covered by switch  
Memory model
6484465 Thread.getState states are under-specified
6584700 17.9 "Sleep and Yield" statement about observable effects
6442525 Syntax specification is inconsistent with other sections
4266845 Explicitly mention that string literals can't contain \u0022
4750181 javac should use grammar from JLS sections 4, 6-10, 14, 15
6674901 Please clarify ReferenceType
7006791 JLS3 4.4 grammar for TypeBound is confusing
7018430 Spelling/formatting errors in JLS3
6678997 Incorrect sample code in JLS3 4.4 Type Variables
7013667 typo in jls 3.0 section 6.3
6502650 Enum sample program (JLS8.9) doesn't compile
4396260 misleadingly incomplete xref in JLS2 15.28 Constant Expression

JLS3 4.4, 4.5, 4.8, 4.12.2: Terminology has been tightened around generics, such as the difference between type variables, type parameters (not "formal type parameters"), and type arguments. The conditions for unchecked warnings, and terminology around heap pollution, have been clarified.

JLS3,, 15.14, 15.15: The meaning of names and final variables has been clarified.

JLS3 5.1.3: Added: "Conversion of a double value to float is governed by the IEEE 754 rounding rules (4.2.4). This conversion can lose precision, but also lose range, resulting in a float zero from a nonzero double and a float infinity from a finite double. A double NaN is converted to a float NaN and a double infinity is converted to the same-signed float infinity."

JLS3 5.1.7, 5.1.8: Boxing and unboxing conversion is specified to occur on values, but obviously works on variables too.

JLS3 8.9.2: An explicit constructor declaration of an enum type must not be public or protected.

JLS3 10.1: References to "component type" throughout the spec (but especially in 10.1 Array Types) have been changed to "element type", sometimes for correctness and sometimes for readability.

JLS3 13.4.12: Changed: "Adding a method ... will not break compatibility with any pre-existing binaries, ***even*** in the case where..." (The word "even" was in JLS1 to subtly point out that Java does not suffer from fragile base classes. JLS2/3 dropped the word "even", but that made informative text appear like an important normative side-condition. It isn't; the word "even" is an important break to indicate an interesting, but ultimately unsurprisingly, informative sidebar.)

JLS3 13.4.14: Changing the type of the last formal parameter of a method from T[] to T... is binary-compatible. (And source-compatible, since old clients which pass a T[] can be recompiled against the changed method declaration, thanks to 8.4.2's definition of T... as T[].)

JLS3 A redundant rule about arity of a potentially applicable member has been removed.

JLS3 15.16: An extra [] in a primitive type cast were erroneously allowed (compare with the copy in 15.15), even though these were technically not part of the target type in the subsequent normative text.

JLS3 17.4.8: Well formed executions E_i,... should not mention O_i.