 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Maintenance Review of JSR 901 (JavaTM Language Specification) for Java SE 7Last 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:
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 EditionOrganization of the SpecificationNormative materialCross-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. 4.5.1.1 Type Argument Containment and 4.12.2.1 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. 15.8.1.1 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 materialIt 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 15.12.2.9 Examples 15.12.2.10 Example: Overloading Ambiguity 15.12.2.11 Example: Return Type Not Considered 15.12.2.12 Example: Compile-Time Resolution 15.13.2 Examples: Array Access Evaluation Order 15.18.1.3 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. 7.4.1.1 Package Annotations was mainly informative, so 7.4.1.1 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 chapterDefects in the Java Language Specification are tracked as bugs in
the Some defects in the Java Language Specification are related to
defects in 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 In addition to the bugs below, Lexical Structure4685937 JLS3 3.10.2 has misleading information on largest/smallest floating-point literals Types6869735 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 Conversions6508599 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 Names6493167 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 Packages4420532 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 Classes6424261 Description of "override" in JLS 3 section 6.4.3 is misleading 4713248 spurious constraint 8.8.5.1 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] Interfaces6505167 Annotations syntax error in JLS 9.7 5008260 @Override should be generalized from 'superclass' to 'supertype' [6399361 CONFORMANCE: @Override specification and compiler inconsistent] Exceptions6554157 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 "except.never.thrown.in.try" have to be reported [6558548 The compiler needs to be aligned with clarified specification of throws] Compiling, Linking, and Compatibility6519118 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 Statements6302175 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 Expressions
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 ++? --? +=?
Expressions->Inference6371674 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 15.12.2.8 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 (15.12.2.8) 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 Assignment4088988 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 model6484465 Thread.getState states are under-specified 6584700 17.9 "Sleep and Yield" statement about observable effects Syntax6442525 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 Miscellaneous7018430 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 6.5.6.1, 6.5.6.2, 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 15.12.2.1: 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. |
