From 77f82a3d4aaf7dc2facd0250b412bf69310ae2a3 Mon Sep 17 00:00:00 2001 From: YujiSoftware Date: Sat, 20 Sep 2025 16:47:00 +0900 Subject: [PATCH 1/3] Update Java SE 25 --- chapter-1.txt | 30 +++++-- chapter-11.txt | 16 ++-- chapter-12.txt | 148 +++++++++++++++++++++++-------- chapter-13.txt | 8 +- chapter-14.txt | 24 +++-- chapter-15.txt | 36 +++++--- chapter-16.txt | 84 +++++++++++++++--- chapter-18.txt | 2 +- chapter-19.txt | 7 +- chapter-2.txt | 2 +- chapter-3.txt | 10 ++- chapter-4.txt | 10 +-- chapter-5.txt | 14 +-- chapter-6.txt | 42 ++++++--- chapter-7.txt | 236 ++++++++++++++++++++++++++++++++++++++++++++++++- chapter-8.txt | 155 +++++++++++++++++++++----------- chapter-9.txt | 2 +- 17 files changed, 653 insertions(+), 173 deletions(-) diff --git a/chapter-1.txt b/chapter-1.txt index f365eb1..9a9c364 100644 --- a/chapter-1.txt +++ b/chapter-1.txt @@ -7,6 +7,8 @@ Table of Contents 1.3. Notation 1.4. Relationship to Predefined Classes and Interfaces 1.5. Preview Features +1.5.1. Restrictions on the Use of Preview Features +1.5.2. Current Preview Language Features 1.6. Feedback 1.7. References @@ -16,7 +18,7 @@ The Java programming language is strongly and statically typed. This specificati The Java programming language is a relatively high-level language, in that details of the machine representation are not available through the language. It includes automatic storage management, typically using a garbage collector, to avoid the safety problems of explicit deallocation (as in C's free or C++'s delete). High-performance garbage-collected implementations can have bounded pauses to support systems programming and real-time applications. The language does not include any unsafe constructs, such as array accesses without index checking, since such unsafe constructs would cause a program to behave in an unspecified way. -The Java programming language is normally compiled to the bytecode instruction set and binary format defined in The Java Virtual Machine Specification, Java SE 24 Edition. +The Java programming language is normally compiled to the bytecode instruction set and binary format defined in The Java Virtual Machine Specification, Java SE 25 Edition. 1.1. Organization of the Specification @@ -111,7 +113,7 @@ Hello, world. Throughout this specification, we refer to classes and interfaces drawn from the Java SE Platform API. Whenever we refer to a class or interface (other than those declared in an example) using a single identifier N, the intended reference is to the class or interface named N in the package java.lang. We use the canonical name (§6.7) for classes or interfaces from packages other than java.lang. -A cross-reference within this specification is shown as (§x.y). Occasionally, we refer to concepts in the The Java Virtual Machine Specification, Java SE 24 Edition via cross-references of the form (JVMS §x.y). +A cross-reference within this specification is shown as (§x.y). Occasionally, we refer to concepts in the The Java Virtual Machine Specification, Java SE 25 Edition via cross-references of the form (JVMS §x.y). Non-normative text, designed to clarify the normative text of this specification, is given in smaller, indented text. @@ -133,21 +135,25 @@ A preview feature is: a new feature of the Java programming language ("preview language feature"), or +a new feature of the Java Virtual Machine ("preview VM feature"), or + a new module, package, class, interface, field, method, constructor, or enum constant in the java.* or javax.* namespace ("preview API") that is fully specified, fully implemented, and yet impermanent. It is available in implementations of a given release of the Java SE Platform to provoke developer feedback based on real world use; this may lead to it becoming permanent in a future release of the Java SE Platform. -Implementations must disable, at both compile time and run time, the preview features defined by a given release of the Java SE Platform, unless the user indicates via the host system, at both compile time and run time, that preview features are to be enabled. - The preview features defined by a given release of the Java SE Platform are enumerated in the Java SE Platform Specification for that release. The preview features are specified as follows: Preview language features are specified in standalone documents that indicate changes ("diffs") to The Java® Language Specification for that release. The specifications of preview language features are incorporated into The Java® Language Specification by reference, and made a part thereof, if and only if preview features are enabled at compile time. -Java SE 24 defines four preview language features: Flexible Constructor Bodies; Simple Source Files and Instance main Methods; Module Import Declarations; and Primitive Types in Patterns, instanceof, and switch. The standalone documents which specify these preview features are available at the web site which hosts this edition of The Java® Language Specification. +Preview VM features are specified in standalone documents that indicate changes ("diffs") to The Java® Virtual Machine Specification for that release. The specifications of preview VM features are incorporated into The Java® Virtual Machine Specification by reference, and made a part thereof, if and only if preview features are enabled at run time. Preview APIs are specified within the Java SE API Specification for that release. -The rules for use of preview language features are as follows: +1.5.1. Restrictions on the Use of Preview Features + +Implementations of the Java SE Platform disable, at both compile time and run time, the preview features defined by a given release, unless the user indicates via the host system, at both compile time and run time, that preview features are enabled. Implementations do not provide a way to enable only some of the given release's preview features. + +At compile time, the rules for use of preview language features are as follows: If preview features are disabled, then any source code reference to a preview language feature, or to a class or interface declared using a preview language feature, causes a compile-time error. @@ -159,7 +165,7 @@ The reference appears in an import declaration (§7.5). When preview features are enabled, Java compilers are strongly encouraged to give a non-suppressible warning for every source code reference to a preview language feature. Details of this warning are beyond the scope of this specification, but the intent should be to alert programmers to the possibility of code being affected by future changes to preview language features. -Some preview APIs are described as reflective by the Java SE Platform Specification, principally in the java.lang.reflect, java.lang.invoke, and javax.lang.model packages. The rule for use of reflective preview APIs is as follows: +Some preview APIs are described as reflective by the Java SE Platform Specification, principally in the java.lang.reflect, java.lang.invoke, and javax.lang.model packages. At compile time, the rule for use of reflective preview APIs is as follows: Whether preview features are enabled or disabled, any source code reference to a reflective preview API element causes a preview warning, unless one of the following is true: @@ -169,7 +175,7 @@ The reference appears in a declaration that is annotated to suppress preview war The reference appears in an import declaration. -All preview APIs not described as reflective in the Java SE Platform Specification are normal. The rules for use of normal preview APIs are as follows: +All preview APIs not described as reflective in the Java SE Platform Specification are normal. At compile time, the rules for use of normal preview APIs are as follows: If preview features are disabled, then any source code reference to a normal preview API element causes a compile-time error, unless: @@ -183,6 +189,14 @@ The reference appears in a declaration that is annotated to suppress preview war The reference appears in an import declaration. +1.5.2. Current Preview Language Features + +Java SE 25 defines one preview language feature: + +Primitive Types in Patterns, instanceof, and switch + +The standalone documents which specify this preview feature are available at the web site which hosts this edition of The Java® Language Specification. + 1.6. Feedback Readers are invited to report technical errors and ambiguities in The Java® Language Specification to jls-jvms-spec-comments@openjdk.org. diff --git a/chapter-11.txt b/chapter-11.txt index 02e6510..063e650 100644 --- a/chapter-11.txt +++ b/chapter-11.txt @@ -8,7 +8,7 @@ Table of Contents 11.1.3. Asynchronous Exceptions 11.2. Compile-Time Checking of Exceptions 11.2.1. Exception Analysis of Expressions -11.2.2. Exception Analysis of Statements +11.2.2. Exception Analysis of Statements and Constructor Invocations 11.2.3. Exception Checking 11.3. Run-Time Handling of an Exception @@ -147,7 +147,7 @@ For every other kind of expression, the expression can throw an exception class Note that a method reference expression (§15.13) of the form Primary :: [TypeArguments] Identifier can throw an exception class if the Primary subexpression can throw an exception class. In contrast, a lambda expression can throw nothing, and has no immediate subexpressions on which to perform exception analysis. It is the body of a lambda expression, containing expressions and statements, that can throw exception classes. -11.2.2. Exception Analysis of Statements +11.2.2. Exception Analysis of Statements and Constructor Invocations A throw statement (§14.18) whose thrown expression has static type E and is not a final or effectively final exception parameter can throw E or any exception class that the thrown expression can throw. @@ -169,12 +169,6 @@ Some catch block of the try statement can throw E and either no finally block is A finally block is present and can throw E. -An explicit constructor invocation statement (§8.8.7.1) can throw an exception class E iff either: - -Some expression of the constructor invocation's parameter list can throw E; or - -E is determined to be an exception class of the throws clause of the constructor that is invoked (§15.12.2.6). - A switch statement (§14.11) can throw an exception class E iff either: The selector expression can throw E; or @@ -183,6 +177,12 @@ Some switch rule expression, switch rule block, switch rule throw statement, or Any other statement S can throw an exception class E iff an expression or statement immediately contained in S can throw E. +A constructor invocation (§8.8.7.1) can throw an exception class E iff either: + +Some expression of the constructor invocation's parameter list can throw E; or + +E is determined to be an exception class of the throws clause of the constructor that is invoked (§15.12.2.6). + 11.2.3. Exception Checking It is a compile-time error if a method or constructor body can throw some exception class E when E is a checked exception class and E is not a subclass of some class declared in the throws clause of the method or constructor. diff --git a/chapter-12.txt b/chapter-12.txt index ce0a675..fb25a52 100644 --- a/chapter-12.txt +++ b/chapter-12.txt @@ -3,10 +3,10 @@ Chapter 12. Execution Table of Contents 12.1. Java Virtual Machine Startup -12.1.1. Load the Class Test -12.1.2. Link Test: Verify, Prepare, (Optionally) Resolve -12.1.3. Initialize Test: Execute Initializers -12.1.4. Invoke Test.main +12.1.1. Load the Initial Class or Interface +12.1.2. Link the Initial Class or Interface: Verify, Prepare, (Optionally) Resolve +12.1.3. Initialize the Initial Class or Interface: Execute Initializers +12.1.4. Invoke a main Method 12.2. Loading of Classes and Interfaces 12.2.1. The Loading Process 12.2.2. Class Loader Consistency @@ -26,82 +26,114 @@ Table of Contents This chapter specifies activities that occur during execution of a program. It is organized around the life cycle of the Java Virtual Machine and of the classes, interfaces, and objects that form a program. -The Java Virtual Machine starts up by loading a specified class or interface, then invoking the method main in this specified class or interface. Section §12.1 outlines the loading, linking, and initialization steps involved in executing main, as an introduction to the concepts in this chapter. Further sections specify the details of loading (§12.2), linking (§12.3), and initialization (§12.4). +The Java Virtual Machine starts up by loading a specified class or interface, then invoking a main method in this specified class or interface. Section §12.1 outlines the loading, linking, and initialization steps involved in executing this method, as an introduction to the concepts in this chapter. Further sections specify the details of loading (§12.2), linking (§12.3), and initialization (§12.4). The chapter continues with a specification of the procedures for creation of new class instances (§12.5); and finalization of class instances (§12.6). It concludes by describing the unloading of classes (§12.7) and the procedure followed when a program exits (§12.8). 12.1. Java Virtual Machine Startup -The Java Virtual Machine starts execution by invoking the method main of some specified class or interface, passing it a single argument which is an array of strings. In the examples in this specification, this first class is typically called Test. +The Java Virtual Machine starts execution by invoking a main method of some specified class or interface. If this method has a formal parameter, it is passed a single argument which is an array of strings. -The precise semantics of Java Virtual Machine startup are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 24 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. +The precise semantics of Java Virtual Machine startup are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 25 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. -The manner in which the initial class or interface is specified to the Java Virtual Machine is beyond the scope of this specification, but it is typical, in host environments that use command lines, for the fully qualified name of the class or interface to be specified as a command line argument and for following command line arguments to be used as strings to be provided as the argument to the method main. +The manner in which the initial class or interface is specified to the Java Virtual Machine is beyond the scope of this specification, but it is typical, in host environments that use command lines, for the fully qualified name of the initial class or interface to be specified as a command line argument and for following command line arguments to be used as strings that are taken as the components of an array that is passed as an argument to the main method. If the original compilation unit was a compact compilation unit (§7.3), then the name of the file that contained the compilation unit, minus any extension, is typically used to specify the name of the initial class or interface. For example, in a UNIX implementation, the command line: java Test reboot Bob Dot Enzo -will typically start a Java Virtual Machine by invoking method main of class Test (a class in an unnamed package), passing it an array containing the four strings "reboot", "Bob", "Dot", and "Enzo". +will typically start a Java Virtual Machine by invoking a main method of class Test (a class in an unnamed package), passing it an argument array containing the four strings "reboot", "Bob", "Dot", and "Enzo". -We now outline the steps the Java Virtual Machine may take to execute Test, as an example of the loading, linking, and initialization processes that are described further in later sections. +Whereas if the file HelloWorld.java contained the following compact compilation unit: -12.1.1. Load the Class Test -The initial attempt to execute the method main of class Test discovers that the class Test is not loaded - that is, that the Java Virtual Machine does not currently contain a binary representation for this class. The Java Virtual Machine then uses a class loader to attempt to find such a binary representation. If this process fails, then an error is thrown. This loading process is described further in §12.2. +void main() { + System.out.println("Hello, World!"); +} + + +which has been compiled, then the command line: + +java HelloWorld + + +will typically start a Java Virtual Machine by invoking the main method of the implicitly declared class (§8.1.8), producing the output: -12.1.2. Link Test: Verify, Prepare, (Optionally) Resolve +Hello, World! -After Test is loaded, it must be initialized before main can be invoked. And Test, like all classes and interfaces, must be linked before it is initialized. Linking involves verification, preparation, and (optionally) resolution. Linking is described further in §12.3. -Verification checks that the loaded representation of Test is well-formed, with a proper symbol table. Verification also checks that the code that implements Test obeys the semantic requirements of the Java programming language and the Java Virtual Machine. If a problem is detected during verification, then an error is thrown. Verification is described further in §12.3.1. +We now outline the steps the Java Virtual Machine may take to execute the initial class or interface; these are described further in later sections. + +12.1.1. Load the Initial Class or Interface + +The attempt to execute a main method of the initial class or interface discovers that it is not loaded - that is, that the Java Virtual Machine does not currently contain a binary representation for this class or interface. The Java Virtual Machine then uses a class loader to attempt to find such a binary representation. If this process fails, then an error is thrown. This loading process is described further in §12.2. + +12.1.2. Link the Initial Class or Interface: Verify, Prepare, (Optionally) Resolve + +After the class or interface is loaded, it must be initialized before a main method can be invoked. The initial class, like all classes and interfaces, must be linked before it is initialized. Linking involves verification, preparation, and (optionally) resolution. Linking is described further in §12.3. + +Verification checks that the loaded representation of the initial class or interface is well-formed, with a proper symbol table. Verification also checks that the code that implements the initial class or interface obeys the semantic requirements of the Java programming language and the Java Virtual Machine. If a problem is detected during verification, then an error is thrown. Verification is described further in §12.3.1. Preparation involves allocation of static storage and any data structures that are used internally by the implementation of the Java Virtual Machine, such as method tables. Preparation is described further in §12.3.2. -Resolution is the process of checking symbolic references from Test to other classes and interfaces, by loading the other classes and interfaces that are mentioned and checking that the references are correct. +Resolution is the process of checking symbolic references from the initial class or interface to other classes and interfaces, by loading the other classes and interfaces that are mentioned and checking that the references are correct. The resolution step is optional at the time of initial linkage. An implementation may resolve symbolic references from a class or interface that is being linked very early, even to the point of resolving all symbolic references from the classes and interfaces that are further referenced, recursively. (This resolution may result in errors from these further loading and linking steps.) This implementation choice represents one extreme and is similar to the kind of "static" linkage that has been done for many years in simple implementations of the C language. (In these implementations, a compiled program is typically represented as an "a.out" file that contains a fully-linked version of the program, including completely resolved links to library routines used by the program. Copies of these library routines are included in the "a.out" file.) -An implementation may instead choose to resolve a symbolic reference only when it is actively used; consistent use of this strategy for all symbolic references would represent the "laziest" form of resolution. In this case, if Test had several symbolic references to another class, then the references might be resolved one at a time, as they are used, or perhaps not at all, if these references were never used during execution of the program. +An implementation may instead choose to resolve a symbolic reference only when it is actively used; consistent use of this strategy for all symbolic references would represent the "laziest" form of resolution. In this case, if the initial class or interface had several symbolic references to another class, then the references might be resolved one at a time, as they are used, or perhaps not at all, if these references were never used during execution of the program. -The only requirement on when resolution is performed is that any errors detected during resolution must be thrown at a point in the program where some action is taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error. Using the "static" example implementation choice described above, loading and linkage errors could occur before the program is executed if they involved a class or interface mentioned in the class Test or any of the further, recursively referenced, classes and interfaces. In a system that implemented the "laziest" resolution, these errors would be thrown only when an incorrect symbolic reference is actively used. +The only requirement on when resolution is performed is that any errors detected during resolution must be thrown at a point in the program where some action is taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error. Using the "static" example implementation choice described above, loading and linkage errors could occur before the program is executed if they involved a class or interface mentioned in the initial class or interface or any of the further, recursively referenced, classes and interfaces. In a system that implemented the "laziest" resolution, these errors would be thrown only when an incorrect symbolic reference is actively used. The resolution process is described further in §12.3.3. -12.1.3. Initialize Test: Execute Initializers +12.1.3. Initialize the Initial Class or Interface: Execute Initializers -In our continuing example, the Java Virtual Machine is still trying to execute the method main of class Test. This is permitted only if the class has been initialized (§12.4.1). +At this stage, the Java Virtual Machine is still trying to execute a main method of the initial class or interface. This is permitted only if the class or interface has been initialized (§12.4.1). -Initialization consists of execution of any class variable initializers and static initializers of the class Test, in textual order. But before Test can be initialized, its direct superclass must be initialized, as well as the direct superclass of its direct superclass, and so on, recursively. In the simplest case, Test has Object as its implicit direct superclass; if class Object has not yet been initialized, then it must be initialized before Test is initialized. Class Object has no superclass, so the recursion terminates here. +Initialization consists of execution of any class variable initializers and static initializers of the initial class or interface, in textual order. But before it can be initialized, its direct superclass must be initialized, as well as the direct superclass of its direct superclass, and so on, recursively. In the simplest case, the initial class has Object as its implicit direct superclass; if class Object has not yet been initialized, then it must be initialized before the initial class or interface is initialized. Class Object has no superclass, so the recursion terminates here. -If class Test has another class Super as its superclass, then Super must be initialized before Test. This requires loading, verifying, and preparing Super if this has not already been done and, depending on the implementation, may also involve resolving the symbolic references from Super and so on, recursively. +If the initial class has another class Super as its superclass, then Super must be initialized before the initial class. This requires loading, verifying, and preparing Super if this has not already been done and, depending on the implementation, may also involve resolving the symbolic references from Super and so on, recursively. Initialization may thus cause loading, linking, and initialization errors, including such errors involving other classes and interfaces. The initialization process is described further in §12.4. -12.1.4. Invoke Test.main +12.1.4. Invoke a main Method + +Finally, after completion of the initialization for the initial class or interface (during which other consequential loading, linking, and initializing may have occurred), a main method declared in, or inherited by, the initial class or interface is invoked. -Finally, after completion of the initialization for class Test (during which other consequential loading, linking, and initializing may have occurred), the method main of Test is invoked. +A main method declared in, or inherited by, a given class is a candidate main method if either: -The method main must be declared public, static, and void. It must specify a formal parameter (§8.4.1) whose declared type is array of String. Therefore, either of the following declarations is acceptable: +It has a single formal parameter (§8.4.1) whose declared type is an array of String, a void result, and public, protected or package access; or +It has no formal parameters, a void result, and public, protected or package access. -public static void main(String[] args) +Note that a candidate main method may be either a static or an instance method. It may optionally have a throws clause (§8.4.6). The type of the single formal parameter may be given as either String[] or String... as they denote the same type. +The form of a candidate main method expanded significantly in Java SE 25. Prior to that, it had to be public, static, and have a single formal parameter; the only variation possible was String[] versus String... for the type of the single formal parameter. +Note that it is not a compile-time error if the initial class or interface counts more than one candidate main methods among its members. -public static void main(String... args) +The presence of a candidate main method in a class or interface may not be immediately apparent because it may be inherited. For example, a default method in an interface is an instance method (§9.4), so may be a candidate main method when inherited by a class that implements the interface. +A candidate main method of the initial class or interface is invoked as if by application of the following rules: + +If there is a candidate main method with a single formal parameter, then this method is invoked. If this method is static then it is invoked directly, passing the argument array (§12.1). If the candidate main method is an instance method then first an instance of the initial class must be created. This class instance is the result of evaluating an unqualified class instance creation expression (§15.9) with no type arguments, no actual arguments, no class body, and where the ClassOrInterfaceTypeToInstantiate is the name of the initial class. The candidate main method is then invoked on the resulting instance, passing the argument array. + +Otherwise, if there is a candidate main method with no formal parameters, then this method is invoked. If this method is static then it is invoked directly. If the candidate main method is an instance method then first an instance of the initial class must be created. This class instance is the result of evaluating an unqualified class instance creation expression (§15.9) with no type arguments, no actual arguments, no class body, and where the ClassOrInterfaceTypeToInstantiate is the name of the initial class. The candidate main method is then invoked on the resulting instance with no actual arguments. + +Note that it is not possible for a class to have both a static and an instance method with the same signature (§8.4.2). + +If there is no candidate main method to invoke, or if creating an instance of the initial class when invoking an instance main method fails, then execution fails; the precise behavior of an implementation in this case is beyond the scope of this specification. 12.2. Loading of Classes and Interfaces Loading refers to the process of finding the binary form of a class or interface with a particular name, perhaps by computing it on the fly, but more typically by retrieving a binary representation previously computed from source code by a Java compiler, and constructing, from that binary form, a Class object to represent the class or interface (§1.4). -The precise semantics of loading are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 24 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. +The precise semantics of loading are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 25 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. -The binary representation of a class or interface is normally the class file format described in Chapter 4 of The Java Virtual Machine Specification, Java SE 24 Edition, but other representations are possible, provided they meet the requirements specified in §13.1. +The binary representation of a class or interface is normally the class file format described in Chapter 4 of The Java Virtual Machine Specification, Java SE 25 Edition, but other representations are possible, provided they meet the requirements specified in §13.1. 12.2.1. The Loading Process @@ -129,13 +161,13 @@ If a class loader L1 delegates loading of a class or interface C to another load A malicious class loader could violate these properties. However, it could not undermine the security of the type system, because the Java Virtual Machine guards against this. -For further discussion of these issues, see The Java Virtual Machine Specification, Java SE 24 Edition and the paper Dynamic Class Loading in the Java Virtual Machine, by Sheng Liang and Gilad Bracha, in Proceedings of OOPSLA '98, published as ACM SIGPLAN Notices, Volume 33, Number 10, October 1998, pages 36-44. A basic principle of the design of the Java programming language is that the run-time type system cannot be subverted by code written in the Java programming language, not even by implementations of sensitive system classes such as ClassLoader. +For further discussion of these issues, see The Java Virtual Machine Specification, Java SE 25 Edition and the paper Dynamic Class Loading in the Java Virtual Machine, by Sheng Liang and Gilad Bracha, in Proceedings of OOPSLA '98, published as ACM SIGPLAN Notices, Volume 33, Number 10, October 1998, pages 36-44. A basic principle of the design of the Java programming language is that the run-time type system cannot be subverted by code written in the Java programming language, not even by implementations of sensitive system classes such as ClassLoader. 12.3. Linking of Classes and Interfaces Linking is the process of taking a binary form of a class or interface and combining it into the run-time state of the Java Virtual Machine, so that it can be executed. A class or interface is always loaded before it is linked. -The precise semantics of linking are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 24 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. +The precise semantics of linking are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 25 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. Three different activities are involved in linking: verification, preparation, and resolution of symbolic references. @@ -387,15 +419,19 @@ Just before a reference to the newly created object is returned as the result, t Assign the arguments for the constructor to newly created parameter variables for this constructor invocation. -If this constructor begins with an explicit constructor invocation (§8.8.7.1) of another constructor in the same class (using this), then evaluate the arguments and process that constructor invocation recursively using these same five steps. If that constructor invocation completes abruptly, then this procedure completes abruptly for the same reason; otherwise, continue with step 5. +If this constructor does not contain an explicit constructor invocation (§8.8.7.1) then continue from step 5. + +Execute the BlockStatements, if any, of the prologue of the constructor body. If execution of any statement completes abruptly, then execution of the constructor completes abruptly for the same reason, otherwise continue with the next step. + +The explicit constructor invocation is either an invocation of another constructor in the same class (using this) or an invocation of a superclass constructor (using super). Evaluate the arguments of the constructor invocation and process the constructor invocation recursively using these same seven steps. If the constructor invocation completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, continue from step 7 if the invocation is of another constructor in the same class, and continue from step 6 if the invocation is of a superclass constructor. -This constructor does not begin with an explicit constructor invocation of another constructor in the same class (using this). If this constructor is for a class other than Object, then this constructor will begin with an explicit or implicit invocation of a superclass constructor (using super). Evaluate the arguments and process that superclass constructor invocation recursively using these same five steps. If that constructor invocation completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, continue with step 4. +If this constructor is for a class other than Object, then this constructor contains an implicit invocation of a superclass constructor with no arguments. In this case, process the implicit constructor invocation recursively using these same seven steps. If that constructor invocation completes abruptly, then this procedure completes abruptly for the same reason, otherwise continue with the next step. -Execute the instance initializers and instance variable initializers for this class, assigning the values of instance variable initializers to the corresponding instance variables, in the left-to-right order in which they appear textually in the source code for the class. If execution of any of these initializers results in an exception, then no further initializers are processed and this procedure completes abruptly with that same exception. Otherwise, continue with step 5. +Execute the instance initializers and instance variable initializers for this class, assigning the values of instance variable initializers to the corresponding instance variables, in the left-to-right order in which they appear textually in the source code for the class. If execution of any of these initializers results in an exception, then no further initializers are processed and this procedure completes abruptly with that same exception, otherwise continue with the next step. -Execute the rest of the body of this constructor. If that execution completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, this procedure completes normally. +Execute the BlockStatements, if any, of the epilogue of this constructor. If execution of any statement completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, this procedure completes normally. -Unlike C++, the Java programming language does not specify altered rules for method dispatch during the creation of a new class instance. If methods are invoked that are overridden in subclasses in the object being initialized, then these overriding methods are used, even before the new object is completely initialized. +Unlike C++, the Java programming language does not specify altered rules for method dispatch during the creation of a new class instance. If methods are invoked that are overridden in subclasses in the object being initialized, then these overriding methods are used, even before the new object is completely initialized. Classes can avoid unwanted exposure of uninitialized state by assigning to their fields in the prologue of the constructor body. Example 12.5-1. Evaluation of Instance Creation @@ -435,7 +471,7 @@ This constructor executes without effect and returns. Next, all initializers for the instance variables of class Point are executed. As it happens, the declarations of x and y do not provide any initialization expressions, so no action is required for this step of the example. Then the body of the Point constructor is executed, setting x to 1 and y to 1. -Next, the initializers for the instance variables of class ColoredPoint are executed. This step assigns the value 0xFF00FF to color. Finally, the rest of the body of the ColoredPoint constructor is executed (the part after the invocation of super); there happen to be no statements in the rest of the body, so no further action is required and initialization is complete. +Next, the initializers for the instance variables of class ColoredPoint are executed. This step assigns the value 0xFF00FF to color. Finally, the epilogue of the ColoredPoint constructor is executed (the part after the invocation of super); there happen to be no statements in the epilogue, so no further action is required and initialization is complete. @@ -467,9 +503,45 @@ This shows that the invocation of printThree in the constructor for class Super + +Example 12.5-3. Initialization of Fields in the Prologue + + +class Super { + Super() { printThree(); } + void printThree() { System.out.println("three"); } +} +class Test extends Super { + int three; + + public Test() { + three = (int)Math.PI; // That is, 3 + super(); + } + + void printThree() { System.out.println(three); } + + public static void main(String[] args) { + Test t = new Test(); + t.printThree(); + } +} + + + +This alternative to Example 12.5-2 produces the output: + +3 +3 + + +Because the field three is initialized in the prologue of the Test constructor, its assignment occurs in Step 3 of the object initialization procedure, before execution of the Super constructor in Step 4. When three is initialized in this way, it is impossible to observe it with the default value 0. + + + 12.6. Finalization of Class Instances -As of Java SE 24, the Java SE Platform Specification allows finalization of class instances to be disabled in an implementation of the Java SE Platform, in anticipation of the removal of finalization from a future release of the Java SE Platform. +As of Java SE 25, the Java SE Platform Specification allows finalization of class instances to be disabled in an implementation of the Java SE Platform, in anticipation of the removal of finalization from a future release of the Java SE Platform. The class Object has a protected method called finalize; this method can be overridden by other classes. The particular definition of finalize that can be invoked for an object is called the finalizer of that object. Before the storage for an object is reclaimed by the garbage collector, the Java Virtual Machine will invoke the finalizer of that object. diff --git a/chapter-13.txt b/chapter-13.txt index aafe0fc..7393570 100644 --- a/chapter-13.txt +++ b/chapter-13.txt @@ -78,7 +78,7 @@ This chapter first specifies some properties that any binary format for the Java 13.1. The Form of a Binary -Programs must be compiled either into the class file format specified by The Java Virtual Machine Specification, Java SE 24 Edition, or into a representation that can be mapped into that format by a class loader written in the Java programming language. +Programs must be compiled either into the class file format specified by The Java Virtual Machine Specification, Java SE 25 Edition, or into a representation that can be mapped into that format by a class loader written in the Java programming language. A class file corresponding to a class or interface declaration must have certain properties. A number of these properties are specifically chosen to support source code transformations that preserve binary compatibility. The required properties are: @@ -86,6 +86,8 @@ The class or interface must be named by its binary name, which must meet the fol The binary name of a top level class or interface (§7.6) is its canonical name (§6.7). +Note that the canonical name of the top level class implicitly declared by a compact compilation unit is determined by the host system (§8.1.8). + The binary name of a member class or interface (§8.5, §9.5) consists of the binary name of its immediately enclosing class or interface, followed by $, followed by the simple name of the member. The binary name of a local class or interface (§14.3) consists of the binary name of its immediately enclosing class or interface, followed by $, followed by a non-empty sequence of digits, followed by the simple name of the local class. @@ -156,7 +158,7 @@ A symbolic reference to the type of each parameter A reference to a method must also include either a symbolic reference to the erasure of the return type of the denoted method or an indication that the denoted method is declared void and does not return a value. -Given a class instance creation expression (§15.9) or an explicit constructor invocation statement (§8.8.7.1) or a method reference expression of the form ClassType :: new (§15.13) in a class or interface C, referencing a constructor m declared in a (possibly distinct) class or interface D, we define the qualifying class of the constructor invocation as follows: +Given a class instance creation expression (§15.9) or an explicit constructor invocation (§8.8.7.1) or a method reference expression of the form ClassType :: new (§15.13) in a class or interface C, referencing a constructor m declared in a (possibly distinct) class or interface D, we define the qualifying class of the constructor invocation as follows: If the expression is of the form new D(...) or ExpressionName.new D(...) or Primary.new D(...) or D :: new, then the qualifying class of the constructor invocation is D. @@ -230,6 +232,8 @@ Certain public methods of interfaces (§9.2) Container annotations (§9.7.5) +Classes implicitly declared by a compact compilation unit (§8.1.8). + A class file corresponding to a module declaration must have the properties of a class file for a class whose binary name is module-info and which has no superclass, no superinterfaces, no fields, and no methods. In addition, the binary representation of the module must contain all of the following: A specification of the name of the module, given as a symbolic reference to the name indicated after module. Also, the specification must include whether the module is normal or open (§7.7). diff --git a/chapter-14.txt b/chapter-14.txt index 777ca62..1a92b10 100644 --- a/chapter-14.txt +++ b/chapter-14.txt @@ -740,7 +740,7 @@ A guard cannot be a constant expression (§15.29) with the value false. The switch block of a switch statement or a switch expression is switch compatible with the type of the selector expression, T, if all of the following are true: -If a null literal is associated with the switch block, then T is a reference type. +If a null literal is associated with the switch block, then T is a reference type, or the null type (§4.1). For every case constant associated with the switch block that names an enum constant, the type of the case constant is assignment compatible with T (§5.2). @@ -1869,6 +1869,8 @@ It is a compile-time error if the return target contains either (i) an instance It is a compile-time error if the return target of a return statement with no value is a method, and that method is not declared void. +It is a compile-time error if the return target of a return statement is a constructor, and the return statement appears in the prologue of this constructor (§8.8.7). + It is a compile-time error if the return target of a return statement with value Expression is either a constructor, or a method that is declared void. It is a compile-time error if the return target of a return statement with value Expression is a method with declared return type T, and the type of Expression is not assignable compatible (§5.2) with T. @@ -2476,11 +2478,23 @@ The block that is the body of a constructor, method, instance initializer, stati An empty block that is not a switch block can complete normally iff it is reachable. -A non-empty block that is not a switch block can complete normally iff the last statement in it can complete normally. +A non-empty block that is not a switch block or a constructor body containing a constructor invocation can complete normally iff the last statement in it can complete normally. + +The first statement in a non-empty block that is not a switch block or a constructor body containing a constructor invocation is reachable iff the block is reachable. + +Every other statement S in a non-empty block that is not a switch block or a constructor body containing a constructor invocation is reachable iff the statement preceding S can complete normally. + +A non-empty block that is the body of a constructor containing a constructor invocation can complete normally iff the last statement in it can complete normally. + +The first statement in a non-empty prologue of a constructor body containing a constructor invocation is reachable iff the block is reachable. + +Every other statement S in the prologue of a constructor body containing a constructor invocation is reachable iff the statement preceding S can complete normally. + +The first statement in a non-empty epilogue of a constructor containing a constructor invocation and an empty prologue is reachable iff the block is reachable. -The first statement in a non-empty block that is not a switch block is reachable iff the block is reachable. +The first statement in a non-empty epilogue of a constructor containing a constructor invocation and a non-empty prologue is reachable iff the last statement of the prologue of the constructor can complete normally. -Every other statement S in a non-empty block that is not a switch block is reachable iff the statement preceding S can complete normally. +Every other statement S in the epilogue of a constructor containing a constructor invocation is reachable iff the statement preceding S can complete normally. A local class declaration statement can complete normally iff it is reachable. @@ -2781,7 +2795,7 @@ record R(ArrayList a){} Given the record pattern R(var b), the type of the pattern variable b is ArrayList. -A type pattern is said to be null matching if it is appears directly in the component pattern list of a record pattern with type R, where the corresponding record component of R has type U, and the type pattern is unconditional for the type U (§14.30.3). +A type pattern is said to be null-matching if it is appears directly in the component pattern list of a record pattern with type R, where the corresponding record component of R has type U, and the type pattern is unconditional for the type U (§14.30.3). Note that this compile-time property of type patterns is used in the run-time process of pattern matching (§14.30.2), so it is associated with the type pattern for use at run time. diff --git a/chapter-15.txt b/chapter-15.txt index 588f3fd..450651d 100644 --- a/chapter-15.txt +++ b/chapter-15.txt @@ -258,7 +258,7 @@ Strict evaluation provides predictable results, but caused performance problems For compatibility, Java 1.2 allowed the programmer to forbid an implementation from using the extended-exponent value sets. The programmer expressed this by placing the strictfp modifier on the declaration of a class, interface, or method. strictfp constrained the floating-point semantics of any enclosed expressions to use the float value set for float expressions and the double value set for double expressions, ensuring the results of such expressions were fully predictable. Code modified by strictfp thus had the same floating-point semantics as specified in Java 1.0 and 1.1. -In Java SE 17 and later, the Java SE Platform always requires strict evaluation of floating-point expressions. Newer members of the processor families that had performance problems implementing strict evaluation no longer have that difficulty. This specification no longer associates float and double with the four value sets described above, and the strictfp modifier no longer affects the evaluation of floating-point expressions. For compatibility, strictfp remains a keyword in Java SE 24 (§3.8) and continues to have restrictions on its use (§8.4.3, §9.4), although Java compilers are encouraged to warn the programmer about its obsolete status. Future versions of the Java programming language may redefine or remove the strictfp keyword. +In Java SE 17 and later, the Java SE Platform always requires strict evaluation of floating-point expressions. Newer members of the processor families that had performance problems implementing strict evaluation no longer have that difficulty. This specification no longer associates float and double with the four value sets described above, and the strictfp modifier no longer affects the evaluation of floating-point expressions. For compatibility, strictfp remains a keyword in Java SE 25 (§3.8) and continues to have restrictions on its use (§8.4.3, §9.4), although Java compilers are encouraged to warn the programmer about its obsolete status. Future versions of the Java programming language may redefine or remove the strictfp keyword. 15.5. Expressions and Run-Time Checks @@ -677,11 +677,15 @@ in the body of an instance method of an interface, that is, a default method or When used as an expression, the keyword this denotes a value that is a reference either to the object for which the instance method was invoked (§15.12), or to the object being constructed. The value denoted by this in a lambda body (§15.27.2) is the same as the value denoted by this in the surrounding context. -The keyword this is also used in explicit constructor invocation statements (§8.8.7.1), and to denote the receiver parameter of a method or constructor (§8.4). +The keyword this is also used in constructor invocations (§8.8.7.1), and to denote the receiver parameter of a method or constructor (§8.4). It is a compile-time error if a this expression occurs in a static context (§8.1.3). -Let C be the innermost enclosing class or interface declaration of a this expression. If C is generic, with type parameters F1,...,Fn, the type of this is C. Otherwise, the type of this is C. +Let C be the innermost enclosing class or interface declaration of a this expression. + +It is a compile-time error if a this expression occurs in an early construction context (§8.8.7) of C, unless it appears as the qualifier of a field access expression (§15.11) that is the left-hand operand of a simple assignment expression (§15.26), and the simple assignment expression is not enclosed in a lambda expression or inner class declaration that is contained in the early construction context of C. + +If C is generic, with type parameters F1,...,Fn, the type of this is C. Otherwise, the type of this is C. At run time, the class of the actual object referred to may be C or a subclass of C (§8.1.5). @@ -718,6 +722,8 @@ If TypeName denotes a generic class, with type parameters F1,...,Fn, the type of It is a compile-time error if a qualified this expression occurs in a static context (§8.1.3). +It is a compile-time error if a qualified this expression occurs in an early construction context (§8.8.7) of the class named by TypeName, unless it appears as the qualifier of a field access expression (§15.11) that is the left-hand operand of a simple assignment expression (§15.26), and the simple assignment expression is not enclosed in a lambda expression or inner class declaration that is contained in the early construction context of the class named by TypeName. + It is a compile-time error if the class or interface whose declaration immediately encloses a qualified this expression is not an inner class of TypeName or TypeName itself. 15.8.5. Parenthesized Expressions @@ -863,6 +869,8 @@ Otherwise, let O be the innermost enclosing class declaration of which C is a me If U is not an inner class of O or O itself, then a compile-time error occurs. +If the class instance creation expression occurs in the early construction context (§8.8.7) of O, then a compile-time error occurs. + Let n be an integer such that O is the n'th lexically enclosing class or interface declaration of U. The immediately enclosing instance of i is the n'th lexically enclosing instance of this. @@ -897,6 +905,8 @@ Otherwise, let O be the innermost enclosing class declaration of which S is a me If U is not an inner class of O or O itself, then a compile-time error occurs. +If the class instance creation expression occurs in the early construction context of O, then a compile-time error occurs. + Let n be an integer such that O is the n'th lexically enclosing class or interface declaration of U. The immediately enclosing instance of i with respect to S is the n'th lexically enclosing instance of this. @@ -1025,7 +1035,7 @@ The new object contains new instances of all the fields declared in the specifie Next, the actual arguments to the constructor are evaluated, left-to-right. If any of the argument evaluations completes abruptly, any argument expressions to its right are not evaluated, and the class instance creation expression completes abruptly for the same reason. -Next, the selected constructor of the specified class is invoked. This results in invoking at least one constructor for each superclass of the class. This process can be directed by explicit constructor invocation statements (§8.8.7.1) and is specified in detail in §12.5. +Next, the selected constructor of the specified class is invoked. This results in invoking at least one constructor for each superclass of the class. This process can be directed by explicit constructor invocations (§8.8.7.1) and is specified in detail in §12.5. The value of a class instance creation expression is a reference to the newly created object of the specified class. Every time the expression is evaluated, a fresh object is created. @@ -1114,7 +1124,7 @@ The actual arguments to the class instance creation expression are used to deter The anonymous constructor body consists of an explicit constructor invocation of the form o.super(...), where o is the first formal parameter of the anonymous constructor, and the actual arguments are the subsequent formal parameters of the constructor, in the order they were declared. The superclass constructor to be invoked is x. -In all cases, the throws clause of an anonymous constructor lists all the checked exceptions thrown by the explicit constructor invocation statement contained in the anonymous constructor, as specified in §15.9.3, and all checked exceptions thrown by any instance initializers or instance variable initializers of the anonymous class. +In all cases, the throws clause of an anonymous constructor lists all the checked exceptions thrown by the explicit constructor invocation contained in the anonymous constructor, as specified in §15.9.3, and all checked exceptions thrown by any instance initializers or instance variable initializers of the anonymous class. Note that it is possible for the signature of the anonymous constructor to refer to an inaccessible type (for example, if such a type occurred in the signature of the superclass constructor x). This does not, in itself, cause any errors at either compile-time or run-time. @@ -1595,7 +1605,7 @@ The form T.super.Identifier refers to the field named Identifier of the lexicall The forms using the keyword super may be used in the locations within a class declaration that allow the keyword this as an expression (§15.8.3). -It is a compile-time error if a field access expression using the keyword super appears in a static context (§8.1.3). +It is a compile-time error if a field access expression using the keyword super occurs in a static context (§8.1.3) or in an early construction context (§8.8.7) of the current class. For a field access expression of the form super.Identifier: @@ -2300,7 +2310,7 @@ If the form is MethodName - that is, just an Identifier - and the compile-time d It is a compile-time error if the method invocation occurs in a static context (§8.1.3). -Otherwise, let T be the class or interface to search (§15.12.1). It is a compile-time error if the innermost enclosing class or interface declaration of the method invocation is neither T nor an inner class of T. +Otherwise, let T be the class or interface to search (§15.12.1). It is a compile-time error if either the method invocation occurs in an early construction context (§8.8.7) of class T, or the innermost enclosing class or interface declaration of the method invocation is neither T nor an inner class of T. If the form is TypeName . [TypeArguments] Identifier, then the compile-time declaration must be static, or a compile-time error occurs. @@ -2310,13 +2320,13 @@ If the form is super . [TypeArguments] Identifier, then: It is a compile-time error if the compile-time declaration is abstract. -It is a compile-time error if the method invocation occurs in a static context. +It is a compile-time error if the method invocation occurs in a static context or in an early construction context of the current class. If the form is TypeName . super . [TypeArguments] Identifier, then: It is a compile-time error if the compile-time declaration is abstract. -It is a compile-time error if the method invocation occurs in a static context. +It is a compile-time error if the method invocation occurs in a static context or in an early construction context of the current class. If TypeName denotes a class C, then if the class or interface declaration immediately enclosing the method invocation is not C or an inner class of C, a compile-time error occurs. @@ -2525,7 +2535,7 @@ Otherwise, an instance method is to be invoked and there is a target reference. If the invocation mode is super, overriding is not allowed. Method m of class or interface C is the one to be invoked. If m is abstract, an AbstractMethodError is thrown. -Otherwise, if the invocation mode is virtual, and Q and m jointly indicate a signature polymorphic method (§15.12.3), then the target object is an instance of java.lang.invoke.MethodHandle or java.lang.invoke.VarHandle. The target object encapsulates state which is matched against the information associated with the method invocation at compile time. Details of this matching are given in The Java Virtual Machine Specification, Java SE 24 Edition and the Java SE Platform API. If matching succeeds, then either the method referenced by the java.lang.invoke.MethodHandle instance is directly and immediately invoked, or the variable represented by the java.lang.invoke.VarHandle instance is directly and immediately accessed, and in either case the procedure in §15.12.4.5 is not executed. If matching fails, then a java.lang.invoke.WrongMethodTypeException is thrown. +Otherwise, if the invocation mode is virtual, and Q and m jointly indicate a signature polymorphic method (§15.12.3), then the target object is an instance of java.lang.invoke.MethodHandle or java.lang.invoke.VarHandle. The target object encapsulates state which is matched against the information associated with the method invocation at compile time. Details of this matching are given in The Java Virtual Machine Specification, Java SE 25 Edition and the Java SE Platform API. If matching succeeds, then either the method referenced by the java.lang.invoke.MethodHandle instance is directly and immediately invoked, or the variable represented by the java.lang.invoke.VarHandle instance is directly and immediately accessed, and in either case the procedure in §15.12.4.5 is not executed. If matching fails, then a java.lang.invoke.WrongMethodTypeException is thrown. Otherwise, the invocation mode is interface or virtual. @@ -2555,7 +2565,7 @@ If the method to be invoked is default, and more than one default method appears If the invocation mode is interface and the method to be invoked is neither public nor private, an IllegalAccessError is thrown. -The above procedure (if it terminates without error) will find a non-abstract, accessible method to invoke, provided that all classes and interfaces in the program have been consistently compiled. However, if this is not the case, then various errors may occur, as specified above; additional details about the behavior of the Java Virtual Machine under these circumstances are given by The Java Virtual Machine Specification, Java SE 24 Edition. +The above procedure (if it terminates without error) will find a non-abstract, accessible method to invoke, provided that all classes and interfaces in the program have been consistently compiled. However, if this is not the case, then various errors may occur, as specified above; additional details about the behavior of the Java Virtual Machine under these circumstances are given by The Java Virtual Machine Specification, Java SE 25 Edition. The dynamic lookup process, while described here explicitly, will often be implemented implicitly, for example as a side-effect of the construction and use of per-class method dispatch tables, or the construction of other per-class structures used for efficient dispatch. @@ -2737,7 +2747,7 @@ If TypeName denotes an interface, I, then let E be the class or interface declar If TypeName denotes a type variable, then a compile-time error occurs. -If a method reference expression has the form super :: [TypeArguments] Identifier or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if the expression occurs in a static context (§8.1.3). +If a method reference expression has the form super :: [TypeArguments] Identifier or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if the expression occurs in a static context (§8.1.3) or in an early construction context (§8.8.7) of the current class. If a method reference expression has the form ClassType :: [TypeArguments] new, then: @@ -2874,7 +2884,7 @@ It is a compile-time error if a method reference expression has the form Referen It is a compile-time error if the method reference expression has the form super :: [TypeArguments] Identifier or TypeName . super :: [TypeArguments] Identifier, and the compile-time declaration is abstract. -It is a compile-time error if the method reference expression has the form super :: [TypeArguments] Identifier or TypeName . super :: [TypeArguments] Identifier, and the method reference expression occurs in a static context (§8.1.3). +It is a compile-time error if the method reference expression has the form super :: [TypeArguments] Identifier or TypeName . super :: [TypeArguments] Identifier, and the method reference expression occurs in a static context (§8.1.3) or in an early construction context (§8.8.7) of the current class. It is a compile-time error if the method reference expression has the form TypeName . super :: [TypeArguments] Identifier, and TypeName denotes a class C, and the immediately enclosing class or interface declaration of the method reference expression is not C or an inner class of C. diff --git a/chapter-16.txt b/chapter-16.txt index dcbc930..aa74c99 100644 --- a/chapter-16.txt +++ b/chapter-16.txt @@ -51,6 +51,8 @@ Such an assignment is defined to occur if and only if either the simple name of For every assignment to a blank final variable, the variable must be definitely unassigned before the assignment, or a compile-time error occurs. +Similarly, for every alternate constructor invocation (§8.8.7.1) occurring in a constructor of a class C, every blank final instance variable of C declared in C must be definitely unassigned after the argument list of the alternate constructor invocation, or a compile-time error occurs. + Note that local variables declared by a pattern (§14.30) are not subject to the rules of definite assignment. Every local variable declared by a pattern is initialized by the process of pattern matching and so always has a value when accessed. The remainder of this chapter is devoted to a precise explanation of the words "definitely assigned before" and "definitely unassigned before". @@ -536,11 +538,11 @@ V is [un]assigned after an empty statement (§14.6) iff it is [un]assigned befor A blank final member field V is definitely assigned (and moreover is not definitely unassigned) before the block (§14.2) that is the body of any method in the scope of V and before the declaration of any class declared within the scope of V. -A local variable V declared by a statement S is definitely unassigned (and moreover is not definitely assigned) before the block that is the body of the constructor, method, instance initializer or static initializer which contains S. +A local variable V declared by a statement S is definitely unassigned (and moreover is not definitely assigned) before the block that is the body of the method, instance initializer or static initializer which contains S. -Let C be a class declared within the scope of V. Then V is definitely assigned before the block that is the body of any constructor, method, instance initializer, or static initializer declared in C iff V is definitely assigned before the declaration of C. +Let C be a class declared within the scope of V. Then V is definitely assigned before the block that is the body of any method, instance initializer, or static initializer declared in C iff V is definitely assigned before the declaration of C. -Note that there are no rules that would allow us to conclude that V is definitely unassigned before the block that is the body of any constructor, method, instance initializer, or static initializer declared in C. We can informally conclude that V is not definitely unassigned before the block that is the body of any constructor, method, instance initializer, or static initializer declared in C, but there is no need for such a rule to be stated explicitly. +Note that there are no rules that would allow us to conclude that V is definitely unassigned before the block that is the body of any method, instance initializer, or static initializer declared in C. We can informally conclude that V is not definitely unassigned before the block that is the body of any method, instance initializer, or static initializer declared in C, but there is no need for such a rule to be stated explicitly. V is [un]assigned after an empty block iff V is [un]assigned before the empty block. @@ -886,28 +888,84 @@ V is definitely assigned (and moreover is not definitely unassigned) before ever Let C be a class declared within the scope of V. Then: -V is definitely assigned before an instance variable initializer (§8.3.2) of C iff V is definitely assigned before the declaration of C. +V is definitely assigned before a constructor declaration (§8.8.7) or instance variable initializer (§8.3.2) of C iff V is definitely assigned before the declaration of C. -Note that there are no rules that would allow us to conclude that V is definitely unassigned before an instance variable initializer. We can informally conclude that V is not definitely unassigned before any instance variable initializer of C, but there is no need for such a rule to be stated explicitly. +Note that there are no rules that would allow us to conclude that V is definitely unassigned before the constructor declaration or instance variable initializer. We can informally conclude that V is not definitely unassigned before any constructor declaration or instance variable initializer of C, but there is no need for such a rule to be stated explicitly. Let C be a class, and let V be a blank final non-static member field of C, declared in C. Then: -V is definitely unassigned (and moreover is not definitely assigned) before the leftmost instance initializer (§8.6) or instance variable initializer of C. +V is definitely unassigned (and moreover is not definitely assigned) before the declaration of any constructor in C. + +V is definitely unassigned (and moreover is not definitely assigned) before the leftmost instance initializer (§8.6) or instance variable initializer of C iff V is definitely unassigned after every superclass constructor invocation (§8.8.7.1) in the constructors of C. + +V is definitely assigned (and moreover is not definitely unassigned) before the leftmost instance initializer (§8.6) or instance variable initializer of C iff C declares at least one constructor, every constructor of C has an explicit constructor invocation, and V is definitely assigned after every superclass constructor invocation in these constructors. V is [un]assigned before an instance initializer or instance variable initializer of C other than the leftmost iff V is [un]assigned after the preceding instance initializer or instance variable initializer of C. +Let C be a class, and let V be a blank final non-static member field of C, declared in a superclass of C. Then: + +V is definitely unassigned (and moreover is not definitely assigned) before the declaration of any constructor in C. + +V is definitely assigned (and moreover is not definitely unassigned) before every instance initializer and instance variable initializer of C. + +Let C be a class, and let V be a blank final static member field of C. Then: + +V is definitely assigned (and moreover is not definitely unassigned) before every constructor declaration, instance initializer, and instance variable initializer of C. + +Let C be a class, and let V be a local variable declared by a statement S contained by a constructor or instance variable initializer of C. Then: + +V is definitely unassigned (and moreover is not definitely assigned) before the constructor declaration or instance variable initializer. + The following rules hold within the constructors (§8.8.7) of class C: -V is definitely assigned (and moreover is not definitely unassigned) after an alternate constructor invocation (§8.8.7.1). +V is [un]assigned before the prologue of the constructor body (§8.8.7) iff V is [un]assigned before the constructor declaration. + +V is [un]assigned after an empty prologue iff V is [un]assigned before the prologue. + +V is [un]assigned after a non-empty prologue iff V is [un]assigned after the last statement in the prologue. + +V is [un]assigned before a constructor invocation (§8.8.7.1) iff V is [un]assigned after the prologue. + +V is [un]assigned before the argument list of a qualified super constructor invocation iff V is [un]assigned after the qualifier expression. + +V is [un]assigned before the argument list of any other constructor invocation iff V is [un]assigned before the invocation. + +V is [un]assigned after the argument list of a constructor invocation iff either V is [un]assigned after the rightmost argument expression in the argument list, or the argument list is empty and V is [un]assigned before the argument list. + +A blank final non-static member field of C, declared in a superclass of C, is definitely assigned (and moreover is not definitely unassigned) after a superclass constructor invocation. + +Any other variable V is [un]assigned after a superclass constructor invocation iff V is [un]assigned after the argument list of the invocation. + +A blank final non-static member field of C, declared in C or a superclass of C, is definitely assigned (and moreover is not definitely unassigned) after an alternate constructor invocation. + +Any other variable V is [un]assigned after an alternate constructor invocation iff V is [un]assigned after the argument list of the invocation. + +For the epilogue of a constructor body with no explicit constructor invocation: + +A blank final non-static member field V of C, declared in C, is [un]assigned before the epilogue iff either V is [un]assigned after the rightmost instance initialization or instance variable initializer of C, or C declares no instance initializer or instance variable initializer, and V is [un]assigned after the prologue of the constructor body. + +A blank final non-static member field of C, declared in a superclass of C, is definitely assigned (and moreover is not definitely unassigned) before the epilogue. + +Any other variable V is [un]assigned before the epilogue iff V is [un]assigned after the prologue of the constructor body. + +For the epilogue of a constructor body with a superclass constructor invocation: + +A blank final non-static member field V of C, declared in C, is [un]assigned before the epilogue iff either V is [un]assigned after the rightmost instance initialization or instance variable initializer of C, or C declares no instance initializer or instance variable initializer, and V is [un]assigned after the superclass constructor invocation. + +Any other variable V is [un]assigned before the epilogue iff V is [un]assigned after the superclass constructor invocation. + +For the epilogue of a constructor body with an alternate constructor invocation, V is [un]assigned before the epilogue iff V is [un]assigned after the alternate constructor invocation. + +V is [un]assigned after an empty epilogue iff V is [un]assigned before the epilogue. -V is definitely unassigned (and moreover is not definitely assigned) before an explicit or implicit superclass constructor invocation (§8.8.7.1). +V is [un]assigned after a non-empty epilogue iff V is [un]assigned after the last statement in the epilogue. -If C has no instance initializers or instance variable initializers, then V is not definitely assigned (and moreover is definitely unassigned) after an explicit or implicit superclass constructor invocation. +V is [un]assigned before the first statement of the prologue or epilogue iff V is [un]assigned before the prologue or epilogue, respectively. -If C has at least one instance initializer or instance variable initializer then V is [un]assigned after an explicit or implicit superclass constructor invocation iff V is [un]assigned after the rightmost instance initializer or instance variable initializer of C. +V is [un]assigned before any other statement S in the prologue or epilogue iff V is [un]assigned after the statement immediately preceding S in the prologue or epilogue. -Let C be a class, and let V be a blank final member field of C, declared in a superclass of C. Then: +V is [un]assigned before the qualifier expression of a super constructor invocation iff V is [un]assigned before the super constructor invocation. -V is definitely assigned (and moreover is not definitely unassigned) before the block that is the body of a constructor or instance initializer of C. +V is [un]assigned before the leftmost argument expression of an explicit constructor invocation iff V is [un]assigned before the argument list. -V is definitely assigned (and moreover is not definitely unassigned) before every instance variable initializer of C. \ No newline at end of file +V is [un]assigned before any other argument expression x of an explicit constructor invocation iff V is [un]assigned after the argument expression to the left of x. \ No newline at end of file diff --git a/chapter-18.txt b/chapter-18.txt index 58782a2..9b9bc92 100644 --- a/chapter-18.txt +++ b/chapter-18.txt @@ -781,7 +781,7 @@ If ei is a switch expression, these rules are applied recursively to each of its While C is not empty, the following process is repeated, starting with the bound set B3 and accumulating new bounds into a "current" bound set, ultimately producing a new bound set, B4: -A subset of constraints is selected in C, satisfying the property that, for each constraint, no input variable can influence an output variable of another constraint in C. The terms input variable and output variable are defined below. An inference variable α can influence an inference variable β if α depends on the resolution of β (§18.4), or vice versa; or if there exists a third inference variable γ such that α can influence γ and γ can influence β. +A subset of constraints is selected in C, satisfying the property that, for each constraint, no input variable can influence an output variable of any other constraint in C. The terms input variable and output variable are defined below. An inference variable α can influence an inference variable β if α depends on the resolution of β (§18.4), or vice versa; or if there exists a third inference variable γ such that α can influence γ and γ can influence β. If this subset is empty, then there is a cycle (or cycles) in the graph of dependencies between constraints. In this case, the constraints in C that participate in a dependency cycle (or cycles) and do not depend on any constraints outside of the cycle (or cycles) are considered. A single constraint is selected from these considered constraints, as follows: diff --git a/chapter-19.txt b/chapter-19.txt index 99e325d..0b73a63 100644 --- a/chapter-19.txt +++ b/chapter-19.txt @@ -112,6 +112,7 @@ Productions from §7 (Packages and Modules) CompilationUnit: OrdinaryCompilationUnit +CompactCompilationUnit ModularCompilationUnit OrdinaryCompilationUnit: [PackageDeclaration] {ImportDeclaration} {TopLevelClassOrInterfaceDeclaration} @@ -126,6 +127,7 @@ SingleTypeImportDeclaration TypeImportOnDemandDeclaration SingleStaticImportDeclaration StaticImportOnDemandDeclaration +SingleModuleImportDeclaration SingleTypeImportDeclaration: import TypeName ; TypeImportOnDemandDeclaration: @@ -278,8 +280,9 @@ ConstructorDeclarator: SimpleTypeName: TypeIdentifier ConstructorBody: -{ [ExplicitConstructorInvocation] [BlockStatements] } -ExplicitConstructorInvocation: +{ [BlockStatements] ConstructorInvocation [BlockStatements] } +{ [BlockStatements] } +ConstructorInvocation: [TypeArguments] this ( [ArgumentList] ) ; [TypeArguments] super ( [ArgumentList] ) ; ExpressionName . [TypeArguments] super ( [ArgumentList] ) ; diff --git a/chapter-2.txt b/chapter-2.txt index 25e07ad..6511013 100644 --- a/chapter-2.txt +++ b/chapter-2.txt @@ -146,4 +146,4 @@ Finally, a few nonterminals are defined by a narrative phrase in roman type wher For example: RawInputCharacter: -any Unicode character \ No newline at end of file +any Unicode character representable in UTF-16 \ No newline at end of file diff --git a/chapter-3.txt b/chapter-3.txt index ae9a1ae..077f8bd 100644 --- a/chapter-3.txt +++ b/chapter-3.txt @@ -80,7 +80,7 @@ HexDigit: (one of) 0 1 2 3 4 5 6 7 8 9 a b c d e f A B C D E F RawInputCharacter: -any Unicode character +any Unicode character representable in UTF-16 The \, u, and hexadecimal digits here are all ASCII characters. @@ -337,7 +337,9 @@ During the reduction of input characters to input elements (§3.5), a sequence o The sequence is recognized as a terminal specified in a suitable context of the syntactic grammar (§2.3), as follows: -For module and open, when recognized as a terminal in a ModuleDeclaration (§7.7). +For module, when recognized as a terminal in a SingleModuleImportDeclaration (§7.5.5), or a ModuleDeclaration (§7.7). + +For open, when recognized as a terminal in a ModuleDeclaration (§7.7). For exports, opens, provides, requires, to, uses, and with, when recognized as a terminal in a ModuleDirective. @@ -695,7 +697,7 @@ The characters CR and LF are never an InputCharacter; each is recognized as cons The character represented by a character literal is the content of the character literal with any escape sequence interpreted, as if by execution of String.translateEscapes on the content. -Character literals can only represent UTF-16 code units (§3.1), i.e., they are limited to values from \u0000 to \uffff. Supplementary characters must be represented either as a surrogate pair within a char sequence, or as an integer, depending on the API they are used with. +Character literals can only represent UTF-16 code units (§3.1), i.e., they are limited to values from \u0000 to \uffff. It is a compile-time error to attempt to represent a supplementary character in a character literal. Supplementary characters must be represented either as a surrogate pair within a char sequence, or as an integer, depending on the API they are used with. The following are examples of char literals: @@ -841,7 +843,7 @@ RawInputCharacter UnicodeEscape: \ UnicodeMarker HexDigit HexDigit HexDigit HexDigit RawInputCharacter: -any Unicode character +any Unicode character representable in UTF-16 A text block is always of type String (§4.3.3). diff --git a/chapter-4.txt b/chapter-4.txt index 491919a..68e192a 100644 --- a/chapter-4.txt +++ b/chapter-4.txt @@ -1332,7 +1332,7 @@ The type in a record component declaration of a record class (§8.10.1) In expressions: -A type in the explicit type argument list to an explicit constructor invocation statement, class instance creation expression, method invocation expression, or method reference expression (§8.8.7.1, §15.9, §15.12, §15.13) +A type in the explicit type argument list to a constructor invocation, class instance creation expression, method invocation expression, or method reference expression (§8.8.7.1, §15.9, §15.12, §15.13) In an unqualified class instance creation expression, as the class type to be instantiated (§15.9) or as the direct superclass type or direct superinterface type of an anonymous class to be instantiated (§15.9.5) @@ -1386,7 +1386,7 @@ In an unqualified class instance creation expression, as the class type to be in In a method reference expression (§15.13), as the reference type to search for a member method or as the class type or array type to construct. -In addition, no wildcard type arguments are permitted in the explicit type argument list to an explicit constructor invocation statement or class instance creation expression or method invocation expression or method reference expression (§8.8.7.1, §15.9, §15.12, §15.13). +In addition, no wildcard type arguments are permitted in the explicit type argument list to a constructor invocation or class instance creation expression or method invocation expression or method reference expression (§8.8.7.1, §15.9, §15.12, §15.13). The following type contexts require that if a type is a parameterized reference type, it has only unbounded wildcard type arguments (i.e. it is a reifiable type) : @@ -1591,7 +1591,7 @@ For every parameter declared in a method declaration, a new parameter variable i Constructor parameters (§8.8.1) name argument values passed to a constructor. -For every parameter declared in a constructor declaration, a new parameter variable is created each time a class instance creation expression (§15.9) or explicit constructor invocation (§8.8.7) invokes that constructor. The new variable is initialized with the corresponding argument value from the creation expression or constructor invocation. The constructor parameter effectively ceases to exist when the execution of the body of the constructor is complete. +For every parameter declared in a constructor declaration, a new parameter variable is created each time a class instance creation expression (§15.9) or constructor invocation (§8.8.7) invokes that constructor. The new variable is initialized with the corresponding argument value from the creation expression or constructor invocation. The constructor parameter effectively ceases to exist when the execution of the body of the constructor is complete. Lambda parameters (§15.27.1) name argument values passed to a lambda expression body (§15.27.2). @@ -1712,7 +1712,7 @@ For all reference types (§4.3), the default value is null. Each method parameter (§8.4.1) is initialized to the corresponding argument value provided by the invoker of the method (§15.12). -Each constructor parameter (§8.8.1) is initialized to the corresponding argument value provided by a class instance creation expression (§15.9) or explicit constructor invocation (§8.8.7). +Each constructor parameter (§8.8.1) is initialized to the corresponding argument value provided by a class instance creation expression (§15.9) or constructor invocation (§8.8.7). An exception parameter (§14.20) is initialized to the thrown object representing the exception (§11.3, §14.18). @@ -1767,7 +1767,7 @@ The correspondence between compile-time types and run-time types is incomplete f At run time, classes and interfaces are loaded by the Java Virtual Machine using class loaders. Each class loader defines its own set of classes and interfaces. As a result, it is possible for two loaders to load an identical class or interface definition but produce distinct classes or interfaces at run time. Consequently, code that compiled correctly may fail at link time if the class loaders that load it are inconsistent. -See the paper Dynamic Class Loading in the Java Virtual Machine, by Sheng Liang and Gilad Bracha, in Proceedings of OOPSLA '98, published as ACM SIGPLAN Notices, Volume 33, Number 10, October 1998, pages 36-44, and The Java Virtual Machine Specification, Java SE 24 Edition for more details. +See the paper Dynamic Class Loading in the Java Virtual Machine, by Sheng Liang and Gilad Bracha, in Proceedings of OOPSLA '98, published as ACM SIGPLAN Notices, Volume 33, Number 10, October 1998, pages 36-44, and The Java Virtual Machine Specification, Java SE 25 Edition for more details. Type variables (§4.4) and type arguments (§4.5.1) are not reified at run time. As a result, the same class or interface at run time represents multiple parameterized types (§4.5) from compile time. Specifically, all compile-time parameterizations of a given generic type (§8.1.2, §9.1.2) share a single run-time representation. diff --git a/chapter-5.txt b/chapter-5.txt index 20a6705..2cc127a 100644 --- a/chapter-5.txt +++ b/chapter-5.txt @@ -692,19 +692,19 @@ The classical open operation on existentials requires that the captured type var Any type may be converted to type String by string conversion. -A value x of primitive type T is first converted to a reference value as if by giving it as an argument to an appropriate class instance creation expression (§15.9): +A value x of primitive type T is first converted to a reference value as if by giving it as an argument to an appropriate method invocation: -If T is boolean, then use new Boolean(x). +If T is boolean, then use Boolean.valueOf(x). -If T is char, then use new Character(x). +If T is char, then use Character.valueOf(x). -If T is byte, short, or int, then use new Integer(x). +If T is byte, short, or int, then use Integer.valueOf(x). -If T is long, then use new Long(x). +If T is long, then use Long.valueOf(x). -If T is float, then use new Float(x). +If T is float, then use Float.valueOf(x). -If T is double, then use new Double(x). +If T is double, then use Double.valueOf(x). This reference value is then converted to type String by string conversion. diff --git a/chapter-6.txt b/chapter-6.txt index 4ef77e6..0e4e370 100644 --- a/chapter-6.txt +++ b/chapter-6.txt @@ -73,11 +73,11 @@ A module, declared in a module declaration (§7.7) A package, declared in a package declaration (§7.4) -An imported class or interface, declared in a single-type-import declaration or a type-import-on-demand declaration (§7.5.1, §7.5.2) +An imported class or interface, declared in a single-type-import declaration, a type-import-on-demand declaration, or a single-module-import declaration (§7.5.1, §7.5.2, §7.5.5) An imported static member, declared in a single-static-import declaration or a static-import-on-demand declaration (§7.5.3, §7.5.4) -A class, declared by a normal class declaration (§8.1), an enum declaration (§8.9), or a record declaration (§8.10) +A class, declared by a normal class declaration (§8.1), an enum declaration (§8.9), a record declaration (§8.10), or implicitly by a compact compilation unit (§7.3) An interface, declared by a normal interface declaration (§9.1) or an annotation interface declaration (§9.6). @@ -433,11 +433,13 @@ The declaration of a subpackage is never in scope. The package java is always in scope. -The scope of a class or interface imported by a single-type-import declaration (§7.5.1) or a type-import-on-demand declaration (§7.5.2) is the module declaration (§7.7) and all the class and interface declarations (§8.1, §9.1) of the compilation unit in which the import declaration appears, as well as any annotations on the module declaration or package declaration of the compilation unit. +The scope of a class or interface imported by a single-type-import declaration (§7.5.1), a type-import-on-demand declaration (§7.5.2), or a single-module-import declaration (§7.5.5) is the module declaration (§7.7) and all the class and interface declarations (§8.1, §9.1) of the compilation unit in which the import declaration appears, as well as any annotations on the module declaration or package declaration of the compilation unit. The scope of a member imported by a single-static-import declaration (§7.5.3) or a static-import-on-demand declaration (§7.5.4) is the module declaration and all the class and interface declarations of the compilation unit in which the import declaration appears, as well as any annotations on the module declaration or package declaration of the compilation unit. -The scope of a top level class or interface (§7.6) is all class and interface declarations in the package in which the top level class or interface is declared. +The scope of a top level class or interface (§7.6) declared in an ordinary compilation unit is all the class and interface declarations in the package in which the top level class or interface is declared. + +The scope of the implicit declaration of a top level class in a compact compilation unit (§7.3) is empty; the class is never in scope. The scope of a declaration of a member m declared in or inherited by a class or interface C (§8.2, §9.2) is the entire body of C, including any nested class or interface declarations. If C is a record class, then the scope of m additionally includes the header of the record declaration of C. @@ -949,9 +951,13 @@ A declaration d of a method named n shadows the declarations of any other method A package declaration never shadows any other declaration. -A type-import-on-demand declaration never causes any other declaration to be shadowed. +A type-import-on-demand declaration d in a compilation unit c of package p that imports a type named n shadows, throughout c, the declarations of any type named n imported by a single-module-import declaration in c. + +In particular, as all compilation units are treated as if they contain the implicit declaration import java.lang.*; (§7.3), this means that the declaration of a type imported by a single-module-import declaration with the same name as one imported from the package java.lang is always shadowed. + +A static-import-on-demand declaration d in a compilation unit c of package p that imports a type named n shadows, throughout c, the declarations of any type named n imported by a single-module-import declaration in c. -A static-import-on-demand declaration never causes any other declaration to be shadowed. +A single-module-import declaration never causes any other declaration to be shadowed. A single-type-import declaration d in a compilation unit c of package p that imports a type named n shadows, throughout c, the declarations of: @@ -961,6 +967,8 @@ any type named n imported by a type-import-on-demand declaration in c any type named n imported by a static-import-on-demand declaration in c +any type named n imported by a single-module-import declaration in c + A single-static-import declaration d in a compilation unit c of package p that imports a field named n shadows the declaration of any static field named n imported by a static-import-on-demand declaration in c, throughout c. A single-static-import declaration d in a compilation unit c of package p that imports a method named n with signature s shadows the declaration of any static method named n with signature s imported by a static-import-on-demand declaration in c, throughout c. @@ -971,7 +979,9 @@ any static type named n imported by a static-import-on-demand declaration in c; any top level type (§7.6) named n declared in another compilation unit (§7.3) of p; -any type named n imported by a type-import-on-demand declaration (§7.5.2) in c. +any type named n imported by a type-import-on-demand declaration (§7.5.2) in c; + +any type named n imported by a single-module-import declaration (§7.5.5) in c. Example 6.4.1-1. Shadowing of a Field Declaration by a Local Variable Declaration @@ -1135,6 +1145,8 @@ In a requires directive in a module declaration (§7.7.1) To the right of to in an exports or opens directive in a module declaration (§7.7.2) +To the right of module in a single-module-import declaration (§7.5.5) + A name is syntactically classified as a PackageName in these contexts: To the right of exports or opens in a module declaration @@ -1193,7 +1205,7 @@ A type in an exception parameter declaration (§14.20) The type in a record component declaration of a record class (§8.10.1) -In an explicit type argument list to an explicit constructor invocation statement or class instance creation expression or method invocation expression (§8.8.7.1, §15.9, §15.12) +In an explicit type argument list to a constructor invocation or class instance creation expression or method invocation expression (§8.8.7.1, §15.9, §15.12) In an unqualified class instance creation expression, either as the class type to be instantiated (§15.9) or as the direct superclass or direct superinterface of an anonymous class to be instantiated (§15.9.5) @@ -1463,15 +1475,19 @@ Otherwise, if there is exactly one declaration denoting either a local variable, Otherwise, a compile-time error occurs. -If the declaration denotes an instance variable of a class C (§8.3.1.1), then both of the following must be true, or a compile-time error occurs: +If the declaration denotes an instance variable of a class C (§8.3.1.1), then all of the following must be true, or a compile-time error occurs: The expression name does not occur in a static context (§8.1.3). +If the expression name occurs in an early construction context of C (§8.8.7), then it is the left-hand operand of a simple assignment expression (§15.26), the declaration of the named variable lacks an initializer, and the simple assignment expression is not enclosed in a lambda expression or inner class declaration that is contained in the early construction context of C. + +The expression name does not occur in an early construction context of a subclass of C. + If the expression name appears in a nested class or interface declaration of C, then the immediately enclosing class or interface declaration of the expression name is an inner class of C. For example, the expression name must not appear in the body of a static method declared by C, nor in the body of an instance method of a static class nested within C. -If the declaration denotes a local variable, formal parameter, or exception parameter, let X be the innermost method declaration, constructor declaration, instance initializer, static initializer, field declaration, or explicit constructor invocation statement which encloses the local variable or parameter declaration. If the expression name appears directly or indirectly in the body of a local class, local interface, or anonymous class D declared directly in X, then both of the following must be true, or a compile-time error occurs: +If the declaration denotes a local variable, formal parameter, or exception parameter, let X be the innermost method declaration, constructor declaration, instance initializer, static initializer, field declaration, or constructor invocation which encloses the local variable or parameter declaration. If the expression name appears directly or indirectly in the body of a local class, local interface, or anonymous class D declared directly in X, then both of the following must be true, or a compile-time error occurs: The expression name does not occur in a static context. @@ -1726,7 +1742,7 @@ The meaning of a name classified as a MethodName is determined as follows. 6.5.7.1. Simple Method Names -A simple method name appears in the context of a method invocation expression (§15.12). The simple method name consists of a single UnqualifiedMethodIdentifier which specifies the name of the method to be invoked. The rules of method invocation require that the UnqualifiedMethodIdentifier denotes a method that is in scope at the point of the method invocation. The rules also prohibit (§15.12.3) a reference to an instance method occurring in a static context (§8.1.3), or in a nested class or interface other than an inner class of the class or interface which declares the instance method. +A simple method name appears in the context of a method invocation expression (§15.12). The simple method name consists of a single UnqualifiedMethodIdentifier which specifies the name of the method to be invoked. The rules of method invocation require that the UnqualifiedMethodIdentifier denotes a method that is in scope at the point of the method invocation. The rules also prohibit (§15.12.3) a reference to an instance method occurring in a static context (§8.1.3), or in a nested class or interface other than an inner class of the class or interface which declares the instance method, or in an early construction context (§8.8.7) of a class where the instance method is a member. Example 6.5.7.1-1. Simple Method Names @@ -1779,7 +1795,7 @@ Some obvious expressions are "missing" from context classification in §6.5.1: f In addition, many statements and expressions allow the use of types that are not expressed exclusively with type names. For example, a class declaration may use a parameterized type (§4.5) to denote the superclass type. Because a parameterized type is not a qualified type name, it is necessary for the class declaration to explicitly perform access control for the denoted superclass. Consequently, of the statements and expressions that provide contexts in §6.5.1 to classify a TypeName, most perform their own access control checks. -Beyond access to members of a package, class, interface, or type parameter, there is the matter of access to constructors of a class. Access control must be checked when a constructor is invoked explicitly or implicitly. Consequently, access control is checked by an explicit constructor invocation statement (§8.8.7.1) and by a class instance creation expression (§15.9.3). Such checks are necessary because §6.5.1 has no mention of explicit constructor invocation statements (as they refer to constructors indirectly, rather than via names) and is unaware of the distinction between the class denoted by an unqualified class instance creation expression and a constructor of that class. Also, constructors do not have qualified names, so we cannot rely on access control being checked during classification of qualified type names. +Beyond access to members of a package, class, interface, or type parameter, there is the matter of access to constructors of a class. Access control must be checked when a constructor is invoked explicitly or implicitly. Consequently, access control is checked by a constructor invocation (§8.8.7.1) and by a class instance creation expression (§15.9.3). Such checks are necessary because §6.5.1 has no mention of constructor invocation (as they refer to constructors indirectly, rather than via names) and is unaware of the distinction between the class denoted by an unqualified class instance creation expression and a constructor of that class. Also, constructors do not have qualified names, so we cannot rely on access control being checked during classification of qualified type names. Accessibility affects inheritance of class members (§8.2), including hiding and method overriding (§8.4.8.1). @@ -2062,6 +2078,8 @@ The fully qualified name of a named package that is a subpackage of another name The fully qualified name of a top level class or top level interface that is declared in an unnamed package is the simple name of the class or interface. +In particular, this means that a top level class that is implicitly declared by a compact compilation unit (§7.3) has a fully qualified name, which is the simple name determined by the host system (§8.1.8). + The fully qualified name of a top level class or top level interface that is declared in a named package consists of the fully qualified name of the package, followed by ".", followed by the simple name of the class or interface. Each member class, member interface, and array type may have a fully qualified name: diff --git a/chapter-7.txt b/chapter-7.txt index 0d0a677..3cab299 100644 --- a/chapter-7.txt +++ b/chapter-7.txt @@ -14,6 +14,7 @@ Table of Contents 7.5.2. Type-Import-on-Demand Declarations 7.5.3. Single-Static-Import Declarations 7.5.4. Static-Import-on-Demand Declarations +7.5.5. Single-Module-Import Declarations 7.6. Top Level Class and Interface Declarations 7.7. Module Declarations 7.7.1. Dependences @@ -164,9 +165,17 @@ CompilationUnit is the goal symbol (§2.1) for the syntactic grammar (§2.3) of CompilationUnit: OrdinaryCompilationUnit +CompactCompilationUnit ModularCompilationUnit OrdinaryCompilationUnit: [PackageDeclaration] {ImportDeclaration} {TopLevelClassOrInterfaceDeclaration} +CompactCompilationUnit: +{ImportDeclaration} {ClassMemberDeclarationNoMethod} MethodDeclaration {ClassMemberDeclaration} +ClassMemberDeclarationNoMethod: +FieldDeclaration +ClassDeclaration +InterfaceDeclaration +; ModularCompilationUnit: {ImportDeclaration} ModuleDeclaration @@ -180,10 +189,33 @@ import declarations (§7.5) that allow classes and interfaces from other package Top level declarations of classes and interfaces (§7.6). +A compact compilation unit consists of a non-empty sequence of class member declarations, at least one of which must be a method declaration (§8.4), optionally preceded by import declarations. Declarations of methods, fields, classes, and interfaces are permitted in any order after the import declarations (if any), as they would be in a class body (§8.1.7). + +This means that the following compilation unit is unambiguously an ordinary compilation unit: + + +import java.util.Vector; +class Test { ... } + + + +whereas the following is unambiguously a compact compilation unit: + + +import java.util.Vector; +static void main(){ ... } +class Test { ... } + + + +A compact compilation unit implicitly declares a top level class (§7.6) whose members are the methods, fields, classes, and interfaces declared in the compact compilation unit. The details of the class are specified in §8.1.8. + A modular compilation unit consists of a module declaration (§7.7), optionally preceded by import declarations. The import declarations allow classes and interfaces from packages in this module and other modules, as well as static members of classes and interfaces, to be referred to using their simple names within the module declaration. Every compilation unit implicitly imports every public class or interface declared in the predefined package java.lang, as if the declaration import java.lang.*; appeared at the beginning of each compilation unit immediately after any package declaration. As a result, the names of all those classes and interfaces are available as simple names in every compilation unit. +Every compact compilation unit implicitly imports all the public top level classes and interfaces of the packages exported by the module java.base, as if the declaration import module java.base; appeared at the beginning of each compact compilation unit (§7.5.5). As a result, the names of all those classes and interfaces are available as simple names in every compact compilation unit. + The host system determines which compilation units are observable, except for the compilation units in the predefined package java and its subpackages lang and io, which are all always observable. Each observable compilation unit may be associated with a module, as follows: @@ -231,7 +263,7 @@ It is recommended that package-info.java, if it is present, take the place of pa 7.4.2. Unnamed Packages -An ordinary compilation unit that has no package declaration, but has at least one other kind of declaration, is part of an unnamed package. +A compact compilation unit, or an ordinary compilation unit that has no package declaration but has at least one other kind of declaration, is part of an unnamed package. Unnamed packages are provided by the Java SE Platform principally for convenience when developing small or temporary applications or when just beginning development. @@ -293,6 +325,7 @@ SingleTypeImportDeclaration TypeImportOnDemandDeclaration SingleStaticImportDeclaration StaticImportOnDemandDeclaration +SingleModuleImportDeclaration A single-type-import declaration (§7.5.1) imports a single named class or interface, by mentioning its canonical name (§6.7). @@ -302,6 +335,8 @@ A single-static-import declaration (§7.5.3) imports all accessible static membe A static-import-on-demand declaration (§7.5.4) imports all accessible static members of a named class or interface as needed, by mentioning the canonical name of the class or interface. +A single-module-import declaration (§7.5.5) imports all the accessible classes and interfaces of the packages exported by a named module, as needed. + The scope and shadowing of a class, interface, or member imported by these declarations is specified in §6.3 and §6.4. An import declaration makes classes, interfaces, or members available by their simple names only within the compilation unit that actually contains the import declaration. The scope of the class(es), interface(s), or member(s) introduced by an import declaration specifically does not include other compilation units in the same package, other import declarations in the current compilation unit, or a package declaration in the current compilation unit (except for the annotations of a package declaration). @@ -492,6 +527,201 @@ It is permissible for one static-import-on-demand declaration to import several If a compilation unit contains both a static-import-on-demand declaration and a type-import-on-demand declaration (§7.5.2) that name the same class or interface, the effect is as if the static member classes and interfaces of that class or interface (§8.5, §9.5) are imported only once. +7.5.5. Single-Module-Import Declarations + +A single-module-import declaration allows all public top level classes and interfaces of the packages exported by a named module to be imported as needed. + +SingleModuleImportDeclaration: +import module ModuleName ; + +A single-module-import declaration imports, on demand, all the public top level classes and interfaces in the following packages: + +The packages exported by the module ModuleName to the current module. + +The packages exported by the modules that are read by the current module due to reading the module ModuleName. This allows a program to use the API of a module, which might refer to classes and interfaces from other modules, without having to import all those other modules. + +It is a compile-time error if the module ModuleName is not read by the current module (§7.3). + +The modules read by the current module are given by the result of resolution, as described in the java.lang.module package specification (§7.3). + +Two or more single-module-import declarations in the same compilation unit may name the same module. All but one of these declarations are considered redundant; the effect is as if that module was imported only once. + +A single-module-import declaration can be used in any source file. It is not required for the source file to be part of a module. For example, modules java.base and java.sql are part of the standard Java runtime, so they can be imported by programs which are not themselves developed as modules. + +It is sometimes useful to import a module that does not export any packages. This is because the module may transitively require other modules that do export packages. For example, the java.se module does not export any packages, but it requires a number of modules transitively, so the effect of the single-module-import declaration import module java.se; is to import the packages which are exported by those modules (and so on, recursively). + +Example 7.5.5-1. Single-Module-Import in Ordinary Compilation Units + +Modules allow a set of packages to be grouped together for reuse under a single name, and the exported packages of a module are intended to form a cohesive and coherent API. Single-module-import declarations allow the developer to import all the packages exported by a module in one go, simplifying the reuse of modular libraries. For example: + + +import module java.xml; + + + +causes the simple names of the public top level classes and interfaces declared in all packages exported by module java.xml to be available within the class and interface declarations of the compilation unit. Thus, the simple name XPath refers to the interface XPath of the package javax.xml.xpath exported by the module java.xml in all places in the compilation unit where that class declaration is not shadowed or obscured. + +Assume the following compilation unit associated with module M0: + + +package q; +import module M1; // What does this import? +class C { ... } + + + +where module M0 has the following declaration: + + +module M0 { requires M1; } + + + +The meaning of the single-module-import declaration import module M1; depends on the exports of M1 and any modules that M1 requires transitively. Consider as an example: + + +module M1 { + exports p1; + exports p2 to M0; + exports p3 to M3; + requires transitive M4; + requires M5; +} + +module M3 { ... } + +module M4 { exports p10; } + +module M5 { exports p11; } + + + +The effect of the single-module-import declaration import module M1; is then: + +Import the public top level classes and interfaces from package p1, since M1 exports p1 to everyone; + +Import the public top level classes and interfaces from package p2, since M1 exports p2 to M0, the module with which the compilation unit is associated; and + +Import the public top level classes and interfaces from package p10, since M1 requires transitively M4, which exports p10. + +Nothing from packages p3 or p11 is imported by the compilation unit. + +Single-module-import declarations may appear in a source file containing only a package declaration. Such files are typically called package-info.java and are used as the sole repository for package-level annotations and documentation (§7.4.1). + + + + +Example 7.5.5-2. Single-Module-Import in Modular Compilation Units + +Import declarations can also appear in a modular compilation unit. The following modular compilation unit uses a single-module-import declaration, allowing the simple name of the interface Driver associated with module java.sql to be used in the provides directive: + + +import module java.sql; +module com.myDB.core { + exports ... + requires transitive java.sql; + provides Driver with com.myDB.greatDriver; +} + + + +It is possible for a modular compilation unit that declares a module to also import that module. In the following example, this means that the simple name of a class C can be used in a uses directive: + + +import module M; +module M { + ... + exports p; + ... + uses C; + ... +} + + + +where the package p exported by module M is declared as follows: + + +package p; +class C { ... } + + + +Without the single-module-import declaration, the qualified name of the class C would need to be used in the uses directive. + +Suppose a module declaration as follows: + + +module M2 { + requires java.se; + exports p2; + ... +} + + + +where the package p2 exported by M2 is declared as follows: + + +package p2; +import module java.xml; +class MyClass { + ... +} + + + +Even though the module M2 does not directly express a dependency on the module java.xml, the import of module java.xml is still correct as the resolution process will determine that the module java.xml is read by module M2. + + + + +Example 7.5.5-3. Ambiguous Imports + +Clearly importing multiple modules could lead to name ambiguities, for example: + + +import module java.base; +import module java.desktop; + +... +List l = ... // Error - Ambiguous name! +... + + + +The module java.base exports the package java.util, which has a public List interface. The module java.desktop exports the package java.awt, which a public List class. Having imported both modules, the use of the simple name List is clearly ambiguous and results in a compile-time error. + +However, just importing a single module can also lead to a name ambiguity, for example: + + +import module java.desktop; + +... +Element e = ... // Error - Ambiguous name! +... + + + +The module java.desktop exports packages javax.swing.text and javax.swing.text.html.parser, which have a public Element interface and a public Element class, respectively. Thus the use of the simple name Element is ambiguous and results in a compile-time error. + +A single-type-import declaration can be used to resolve a name ambiguity. The earlier example where the simple name List is ambiguous can be resolved as follows: + + +import module java.base; +import module java.desktop; + +import java.util.List; // Resolving the ambiguity + // of the simple name List + +... +List l = ... // Ok - List is resolved to + // java.util.List +... + + + + 7.6. Top Level Class and Interface Declarations A top level class or interface declaration declares a top level class (§8.1) or a top level interface (§9.1). @@ -503,6 +733,8 @@ InterfaceDeclaration Extra ";" tokens appearing at the level of class and interface declarations in a compilation unit have no effect on the meaning of the compilation unit. Stray semicolons are permitted in the Java programming language solely as a concession to C++ programmers who are used to placing ";" after a class declaration. They should not be used in new Java code. +A top level class may also be implicitly declared (§8.1.8) by a compact compilation unit. + In the absence of an access modifier, a top level class or interface has package access: it is accessible only within ordinary compilation units of the package in which it is declared (§6.6.1). A class or interface may be declared public to grant access to the class or interface from code in other packages of the same module, and potentially from code in packages of other modules. It is a compile-time error if a top level class or interface declaration contains any one of the following access modifiers: protected, private, or static. @@ -694,7 +926,7 @@ The requires keyword may be followed by the modifier static. This specifies that It is a compile-time error if the same modifier appears more than once following the requires keyword. -If the declaration of a module expresses a dependence on the java.base module, and the module is not itself java.base, then it is a compile-time error if a modifier appears after the requires keyword. +If the declaration of a module expresses a dependence on the java.base module, and the module is not itself java.base, then it is a compile-time error if the static modifier appears after the requires keyword. It is a compile-time error if more than one requires directive in a module declaration specifies the same module name. diff --git a/chapter-8.txt b/chapter-8.txt index 780410b..8d60707 100644 --- a/chapter-8.txt +++ b/chapter-8.txt @@ -14,6 +14,7 @@ Table of Contents 8.1.5. Superinterfaces 8.1.6. Permitted Direct Subclasses 8.1.7. Class Body and Member Declarations +8.1.8. Implicitly Declared Classes 8.2. Class Members 8.3. Field Declarations 8.3.1. Field Modifiers @@ -54,7 +55,7 @@ Table of Contents 8.8.5. Constructor Throws 8.8.6. The Type of a Constructor 8.8.7. Constructor Body -8.8.7.1. Explicit Constructor Invocations +8.8.7.1. Constructor Invocations 8.8.8. Constructor Overloading 8.8.9. Default Constructor 8.8.10. Preventing Instantiation of a Class @@ -76,7 +77,7 @@ A top level class (§7.6) is a class declared directly in a compilation unit. A nested class is any class whose declaration occurs within the body of another class or interface declaration. A nested class may be a member class (§8.5, §9.5), a local class (§14.3), or an anonymous class (§15.9.5). -Some kinds of nested class are an inner class (§8.1.3), which is a class that can refer to enclosing class instances, local variables, and type variables. +A nested class may be inner (§8.1.3), in which case it may (depending on precisely where its declaration occurs) be able to refer to enclosing class instances, local variables, and type variables. An enum class (§8.9) is a class declared with abbreviated syntax that defines a small set of named class instances. @@ -123,7 +124,7 @@ RecordDeclaration NormalClassDeclaration: {ClassModifier} class TypeIdentifier [TypeParameters] [ClassExtends] [ClassImplements] [ClassPermits] ClassBody -A class is also implicitly declared by a class instance creation expression (§15.9.5) and an enum constant that ends with a class body (§8.9.1). +Some classes are implicitly declared by other constructs (§8.1.8). The TypeIdentifier in a class declaration specifies the name of the class. @@ -377,8 +378,8 @@ class Test { new Seq())); Seq nums = new Seq( - new Integer(1), - new Seq(new Double(1.5), + Integer.valueOf(1), + new Seq(Double.valueOf(1.5), new Seq())); Seq.Zipper zipper = @@ -464,11 +465,9 @@ field declaration, constructor declaration, -instance initializer, +instance initializer, or -static initializer, or - -explicit constructor invocation statement +static initializer. which encloses the construct is one of the following: @@ -478,11 +477,9 @@ a static field declaration (§8.3.1.1, §9.3) a static initializer (§8.7) -an explicit constructor invocation statement (§8.8.7.1) - Note that a construct which appears in a constructor declaration or an instance initializer does not occur in a static context. -The purpose of a static context is to demarcate code that must not refer explicitly or implicitly to the current instance of the class whose declaration lexically encloses the static context. Consequently, code that occurs in a static context is restricted in the following ways: +The purpose of a static context is to demarcate code for which there is no current instance defined of the class whose declaration lexically encloses the static context. Consequently, code that occurs in a static context is restricted in the following ways: this expressions (both unqualified and qualified) are disallowed (§15.8.3, §15.8.4). @@ -512,7 +509,7 @@ A class or interface O is the zeroth lexically enclosing class or interface decl A class O is the n'th lexically enclosing class declaration of a class C if it is the immediately enclosing class declaration of the n-1'th lexically enclosing class declaration of C. -An instance i of a direct inner class C of a class or interface O is associated with an instance of O, known as the immediately enclosing instance of i. The immediately enclosing instance of an object, if any, is determined when the object is created (§15.9.2). +An instance i of a direct inner class C of a class or interface O may be associated with an instance of O, known as the immediately enclosing instance of i. The immediately enclosing instance of an object, if any, is determined when the object is created (§15.9.2). An object o is the zeroth lexically enclosing instance of itself. @@ -520,9 +517,9 @@ An object o is the n'th lexically enclosing instance of an instance i if it is t An instance of an inner local class or an anonymous class whose declaration occurs in a static context has no immediately enclosing instance. Also, an instance of a static nested class (§8.1.1.4) has no immediately enclosing instance. -For every superclass S of C which is itself a direct inner class of a class or interface SO, there is an instance of SO associated with i, known as the immediately enclosing instance of i with respect to S. The immediately enclosing instance of an object with respect to its class' direct superclass, if any, is determined when the superclass constructor is invoked via an explicit constructor invocation statement (§8.8.7.1). +For every superclass S of C which is itself a direct inner class of a class or interface SO, there is an instance of SO associated with i, known as the immediately enclosing instance of i with respect to S. The immediately enclosing instance of an object with respect to its class' direct superclass, if any, is determined when the superclass constructor is invoked via a constructor invocation (§8.8.7.1). -When an inner class (whose declaration does not occur in a static context) refers to an instance variable that is a member of a lexically enclosing class or interface declaration, the variable of the corresponding lexically enclosing instance is used. +When an inner class contains a valid reference to an instance variable that is a member of a lexically enclosing class or interface declaration, the variable of the corresponding lexically enclosing instance is used. Any local variable, formal parameter, or exception parameter used but not declared in an inner class must either be final or effectively final (§4.12.4), as specified in §6.5.6.1. @@ -903,6 +900,54 @@ The scope and shadowing of a declaration of a member m declared in or inherited If C is a nested class, there may be definitions of the same kind (variable, method, or type) and name as m in enclosing scopes. (The scopes may be blocks, classes, or packages.) In all such cases, the member m declared in or inherited by C shadows the other definitions of the same kind and name. +8.1.8. Implicitly Declared Classes + +Not all classes are specified by a class declaration. The following constructs implicitly declare classes: + +a class instance creation expression that ends with a class body (§15.9.5) + +an enum constant that ends with a class body (§8.9.1) + +a compact compilation unit (§7.3) + +In all cases, the members of any implicitly declared class, including any implicitly declared members, are subject to the usual rules for member declarations in a class. + +The following production from §7.3 is shown here for convenience: + +CompactCompilationUnit: +{ImportDeclaration} {ClassMemberDeclarationNoMethod} MethodDeclaration {ClassMemberDeclaration} +ClassMemberDeclarationNoMethod: +FieldDeclaration +ClassDeclaration +InterfaceDeclaration +; + +The class implicitly declared by a compact compilation unit satisfies the following properties: + +It is a top level class (§7.6). + +Its name is a valid identifier (§3.8) determined by the host system. + +In simple implementations of the Java SE Platform, where compilation units are stored in files, the name of this implicitly declared class would typically be the name of the file containing the compact compilation unit minus any extension (such as .java or .jav). + +It is not abstract (§8.1.1.1). + +It is final (§8.1.1.2). + +It is a member of an unnamed package (§7.4.2) and has package access. + +Its direct superclass is Object (§8.1.4). + +It does not have any direct superinterfaces (§8.1.5). + +The body of the class contains every class member declared in the compact compilation unit (these are declarations of fields (§8.3), methods (§8.4), member classes (§8.5), and member interfaces (§9.1.1.3)). It is not possible for a compact compilation unit to contain declarations of instance initializers (§8.6), static initializers (§8.7), or constructors (§8.8). + +It has an implicitly declared default constructor (§8.8.9). + +It is a compile-time error if this class does not declare at least one candidate main method (§12.1.4). + +Note that an unnamed package may have multiple implicitly declared classes as members. + 8.2. Class Members The members of a class are all of the following: @@ -3033,7 +3078,7 @@ A generic constructor declaration defines a set of constructors, one for each po The scope and shadowing of a constructor's type parameter is specified in §6.3 and §6.4.1. -References to a constructor's type parameter from an explicit constructor invocation statement or a nested class or interface are restricted, as specified in §6.5.5.1. +References to a constructor's type parameter from a constructor invocation or a nested class or interface are restricted, as specified in §6.5.5.1. 8.8.5. Constructor Throws @@ -3045,18 +3090,21 @@ The type of a constructor consists of its signature and the exception types give 8.8.7. Constructor Body -The first statement of a constructor body may be an explicit invocation of another constructor of the same class or of the direct superclass (§8.8.7.1). +A constructor body is a block of code that is executed as part of the process of creating a new instance of a class (§12.5). A constructor body may contain an explicit invocation of another constructor of the same class or of the direct superclass (§8.8.7.1). ConstructorBody: -{ [ExplicitConstructorInvocation] [BlockStatements] } +{ [BlockStatements] ConstructorInvocation [BlockStatements] } +{ [BlockStatements] } + +If a constructor body contains an explicit constructor invocation, the BlockStatements preceding the constructor invocation are called the prologue of the constructor body. The prologue of a constructor body may be empty. The BlockStatements in a constructor with no explicit constructor invocation and the BlockStatements following a constructor invocation in a constructor body are called the epilogue. The epilogue of a constructor body may also be empty. -It is a compile-time error for a constructor to directly or indirectly invoke itself through a series of one or more explicit constructor invocations involving this. +A construct (statement, local variable declaration statement, local class declaration, local interface declaration, or expression) occurs in the early construction context of a class C if it is contained in either the prologue of a constructor body of C, or it is nested in the constructor invocation (§8.8.7.1) of a constructor body of C. -If a constructor body does not begin with an explicit constructor invocation and the constructor being declared is not part of the primordial class Object, then the constructor body implicitly begins with a superclass constructor invocation "super();", an invocation of the constructor of its direct superclass that takes no arguments. +If a constructor body does not contain an explicit constructor invocation and the constructor being declared is not part of the primordial class Object, then the constructor body (i) has an empty prologue, (ii) implicitly begins with a superclass constructor invocation "super();", an implicit invocation of the constructor of the direct superclass that takes no arguments, and (iii) the statements, if any, given in the constructor body are taken to form the epilogue of the constructor body. -Except for the possibility of explicit constructor invocations, and the prohibition on explicitly returning a value (§14.17), the body of a constructor is like the body of a method (§8.4.7). +Except for the possibility of explicit or implicit constructor invocations, and the prohibition on return statements (§14.17), the body of a constructor is like the body of a method (§8.4.7). -A return statement (§14.17) may be used in the body of a constructor if it does not include an expression. +Note that a constructor body contains at most one constructor invocation. The grammar makes it impossible, for example, to place constructor invocations in different branches of an if statement. Example 8.8.7-1. Constructor Bodies @@ -3081,8 +3129,8 @@ Here, the first constructor of ColoredPoint invokes the second, providing an add -8.8.7.1. Explicit Constructor Invocations -ExplicitConstructorInvocation: +8.8.7.1. Constructor Invocations +ConstructorInvocation: [TypeArguments] this ( [ArgumentList] ) ; [TypeArguments] super ( [ArgumentList] ) ; ExpressionName . [TypeArguments] super ( [ArgumentList] ) ; @@ -3095,7 +3143,7 @@ TypeArguments: ArgumentList: Expression {, Expression} -Explicit constructor invocation statements are divided into two kinds: +Constructor invocations are divided into two kinds: Alternate constructor invocations begin with the keyword this (possibly prefaced with explicit type arguments). They are used to invoke an alternate constructor of the same class. @@ -3105,35 +3153,35 @@ Unqualified superclass constructor invocations begin with the keyword super (pos Qualified superclass constructor invocations begin with a Primary expression or an ExpressionName. They allow a subclass constructor to explicitly specify the newly created object's immediately enclosing instance with respect to the direct superclass (§8.1.3). This may be necessary when the superclass is an inner class. -An explicit constructor invocation statement introduces a static context (§8.1.3), which limits the use of constructs that refer to the current object. Notably, the keywords this and super are prohibited in a static context (§15.8.3, §15.11.2), as are unqualified references to instance variables, instance methods, and type parameters of lexically enclosing declarations (§6.5.5.1, §6.5.6.1, §15.12.3). +It is a compile-time error for a constructor to directly or indirectly invoke itself through a series of one or more alternate constructor invocations. + +A constructor invocation introduces an early construction context (§8.8.7), which limits the use of constructs that refer to the current object. Notably, references to the current object using this and super are restricted in an early construction context (§15.8.3, §15.11.2), as are references to instance variables (§6.5.6.1) and instance methods (§6.5.7.1). If TypeArguments is present to the left of this or super, then it is a compile-time error if any of the type arguments are wildcards (§4.5.1). Let C be the class being instantiated, and let S be the direct superclass of C. -If a superclass constructor invocation statement is unqualified, then: +If a superclass constructor invocation is unqualified, then: If S is an inner member class, but S is not a member of a class enclosing C, then a compile-time error occurs. -Otherwise, let O be the innermost enclosing class of C of which S is a member. C must be an inner class of O (§8.1.3), or a compile-time error occurs. +Otherwise, let O be the innermost enclosing class of C of which S is a member. C must be an inner class of O (§8.1.3), or a compile-time error occurs. If the superclass constructor invocation occurs in an early construction context of the class O, then a compile-time error occurs. If S is an inner local class, and S does not occur in a static context, let O be the immediately enclosing class or interface declaration of S. C must be an inner class of O, or a compile-time error occurs. If S is a inner local class whose declaration occurs in a static context, then let N be the nearest static method declaration, static field declaration, or static initializer that encloses the declaration of S. If N is not the nearest static method declaration, static field declaration, or static initializer that encloses the superclass constructor invocation, then a compile-time error occurs. -If a superclass constructor invocation statement is qualified, then: +If a superclass constructor invocation is qualified, then: If S is not an inner class, or if the declaration of S occurs in a static context, then a compile-time error occurs. Otherwise, let p be the Primary expression or the ExpressionName immediately preceding ".super", and let O be the immediately enclosing class of S. It is a compile-time error if the type of p is not O or a subclass of O, or if the type of p is not accessible (§6.6). -The exception types that an explicit constructor invocation statement can throw are specified in §11.2.2. - -Evaluation of an alternate constructor invocation statement proceeds by first evaluating the arguments to the constructor, left-to-right, as in an ordinary method invocation; and then invoking the constructor. +The exception types that an explicit constructor invocation can throw are specified in §11.2.2. -Evaluation of a superclass constructor invocation statement proceeds as follows: +Evaluation of an alternate constructor invocation proceeds by first evaluating the arguments to the constructor, left-to-right, as in an ordinary method invocation; and then invoking the constructor. -Let i be the instance being created. The immediately enclosing instance of i with respect to S (if any) must be determined: +Let i be the instance being created by a superclass constructor invocation. The immediately enclosing instance of i with respect to S (if any) is determined as follows: If S is not an inner class, or if the declaration of S occurs in a static context, then no immediately enclosing instance of i with respect to S exists. @@ -3141,7 +3189,7 @@ Otherwise, if the superclass constructor invocation is unqualified, then S is ne If S is an inner local class, let O be the immediately enclosing class or interface declaration of S. -If S is an inner member class, let O be the innermost enclosing class of C of which S is a member. +If S is an inner member class, let O be the innermost enclosing class of C of which S is a member. If the superclass constructor invocation occurs in the early construction context of the class O, then a compile-time error occurs. Let n be an integer (n ≥ 1) such that O is the n'th lexically enclosing class or interface declaration of C. @@ -3149,19 +3197,23 @@ The immediately enclosing instance of i with respect to S is the n'th lexically While it may be the case that S is a member of C due to inheritance, the zeroth lexically enclosing instance of this (that is, this itself) is never used as the immediately enclosing instance of i with respect to S. -Otherwise, if the superclass constructor invocation is qualified, then the Primary expression or the ExpressionName immediately preceding ".super", p, is evaluated. +Otherwise, if the superclass constructor invocation is qualified, then the immediately enclosing instance of i with respect to S is the object that is the value of the Primary expression or the ExpressionName. + +If the superclass constructor invocation has an immediately enclosing instance then this instance is taken to be the first actual argument to the constructor invocation, and the subsequent actual arguments to the constructor invocation are taken to be the arguments in the argument list of superclass constructor invocation, if any, in the order that they appear. Otherwise the actual arguments to the constructor invocation are taken to be the arguments in the superclass constructor invocation, if any, in the order that they appear. + +Evaluation of a superclass constructor invocation then proceeds as follows: -If p evaluates to null, a NullPointerException is raised, and the superclass constructor invocation completes abruptly. +First, if the superclass constructor invocation is qualified, the Primary expression or the ExpressionName is evaluated. If it evaluates to null, a NullPointerException is raised and the superclass constructor invocation completes abruptly. If this evaluation completes abruptly, then the superclass constructor invocation completes abruptly for the same reason. -Otherwise, the result of this evaluation is the immediately enclosing instance of i with respect to S. +The actual arguments to the constructor invocation are evaluated, left-to-right, as in an ordinary method invocation; then the constructor is invoked. -After determining the immediately enclosing instance of i with respect to S (if any), evaluation of the superclass constructor invocation statement proceeds by evaluating the arguments to the constructor, left-to-right, as in an ordinary method invocation; and then invoking the constructor. +Recall that the first actual argument to the constructor invocation may be an enclosing instance. -Finally, if the superclass constructor invocation statement completes normally, then all instance variable initializers of C and all instance initializers of C are executed. If an instance initializer or instance variable initializer I textually precedes another instance initializer or instance variable initializer J, then I is executed before J. +Finally, if the superclass constructor invocation completes normally, then all instance variable initializers of C and all instance initializers of C are executed. If an instance initializer or instance variable initializer I textually precedes another instance initializer or instance variable initializer J, then I is executed before J. -Execution of instance variable initializers and instance initializers is performed regardless of whether the superclass constructor invocation actually appears as an explicit constructor invocation statement or is provided implicitly. (An alternate constructor invocation does not perform this additional implicit execution.) +Execution of instance variable initializers and instance initializers is performed regardless of whether the superclass constructor invocation actually appears as an explicit constructor invocation or is provided implicitly. (An alternate constructor invocation does not perform this additional implicit execution.) -Example 8.8.7.1-1. Restrictions on Explicit Constructor Invocation Statements +Example 8.8.7.1-1. Restrictions on Constructor Invocations If the first constructor of ColoredPoint in the example from §8.8.7 were changed as follows: @@ -3182,14 +3234,14 @@ class ColoredPoint extends Point { } -then a compile-time error would occur, because the instance variable color cannot be used by a explicit constructor invocation statement. +then a compile-time error would occur, because the instance variable color cannot be used by a constructor invocation. Example 8.8.7.1-2. Qualified Superclass Constructor Invocation -In the code below, ChildOfInner has no lexically enclosing class or interface declaration, so an instance of ChildOfInner has no enclosing instance. However, the superclass of ChildOfInner (Inner) has a lexically enclosing class declaration (Outer), and an instance of Inner must have an enclosing instance of Outer. The enclosing instance of Outer is set when an instance of Inner is created. Therefore, when we create an instance of ChildOfInner, which is implicitly an instance of Inner, we must provide the enclosing instance of Outer via a qualified superclass invocation statement in ChildOfInner's constructor. The instance of Outer is called the immediately enclosing instance of ChildOfInner with respect to Inner. +In the code below, ChildOfInner has no lexically enclosing class or interface declaration, so an instance of ChildOfInner has no enclosing instance. However, the superclass of ChildOfInner (Inner) has a lexically enclosing class declaration (Outer), and an instance of Inner must have an enclosing instance of Outer. The enclosing instance of Outer is set when an instance of Inner is created. Therefore, when we create an instance of ChildOfInner, which is implicitly an instance of Inner, we must provide the enclosing instance of Outer via a qualified superclass invocation in ChildOfInner's constructor. The instance of Outer is called the immediately enclosing instance of ChildOfInner with respect to Inner. class Outer { class Inner {} @@ -3199,7 +3251,7 @@ class ChildOfInner extends Outer.Inner { } -Perhaps surprisingly, the same instance of Outer may serve as the immediately enclosing instance of ChildOfInner with respect to Inner for multiple instances of ChildOfInner. These instances of ChildOfInner are implicitly linked to the same instance of Outer. The program below achieves this by passing an instance of Outer to the constructor of ChildOfInner, which uses the instance in a qualified superclass constructor invocation statement. The rules for an explicit constructor invocation statement do not prohibit using formal parameters of the constructor that contains the statement. +Perhaps surprisingly, the same instance of Outer may serve as the immediately enclosing instance of ChildOfInner with respect to Inner for multiple instances of ChildOfInner. These instances of ChildOfInner are implicitly linked to the same instance of Outer. The program below achieves this by passing an instance of Outer to the constructor of ChildOfInner, which uses the instance in a qualified superclass constructor invocation. The rules for a constructor invocation do not prohibit using formal parameters of the constructor that contains the invocation. class Outer { int secret = 5; @@ -3249,7 +3301,7 @@ The default constructor has no formal parameters, except in a non-private inner The default constructor has no throws clause. -If the class being declared is the primordial class Object, then the default constructor has an empty body. Otherwise, the default constructor simply invokes the superclass constructor with no arguments. +If the class being declared is the primordial class Object, then the default constructor has an empty body. Otherwise, the default constructor simply invokes the superclass constructor with no arguments. This superclass constructor invocation must satisfy all the rules for an unqualified superclass constructor invocation (§8.8.7.1). The form of the default constructor for an anonymous class is specified in §15.9.5.1. @@ -3426,7 +3478,7 @@ Any constructor or member declarations in the body of an enum declaration apply It is a compile-time error if a constructor declaration in an enum declaration is public or protected (§6.6). -It is a compile-time error if a constructor declaration in an enum declaration contains a superclass constructor invocation statement (§8.8.7.1). +It is a compile-time error if a constructor declaration in an enum declaration contains a superclass constructor invocation (§8.8.7.1). It is a compile-time error to refer to a static field of an enum class from a constructor, instance initializer, or instance variable initializer in the enum declaration of the class, unless the field is a constant variable (§4.12.4). @@ -3972,7 +4024,7 @@ If the record component is a variable arity record component, then the derived f The derived formal parameter is annotated with the annotations, if any, that appear on the record component and whose annotation interfaces are applicable in the formal parameter context, or in type contexts, or both (§9.7.4). -A record declaration may contain declarations of constructors that are not canonical constructors. The body of every non-canonical constructor in a record declaration must start with an alternate constructor invocation (§8.8.7.1), or a compile-time error occurs. +A record declaration may contain declarations of constructors that are not canonical constructors. The body of every non-canonical constructor in a record declaration must contain an alternate constructor invocation (§8.8.7.1), or a compile-time error occurs. 8.10.4.1. Normal Canonical Constructors @@ -3992,7 +4044,7 @@ The constructor must not be generic (§8.8.4). The constructor must not have a throws clause. -The constructor body must not contain an explicit constructor invocation statement (§8.8.7.1). +The constructor body must not contain an explicit constructor invocation (§8.8.7.1). All the other rules for constructor declarations in a normal class declaration must be satisfied (§8.8). @@ -4025,7 +4077,8 @@ Annotation public protected private SimpleTypeName: TypeIdentifier ConstructorBody: -{ [ExplicitConstructorInvocation] [BlockStatements] } +{ [BlockStatements] ConstructorInvocation [BlockStatements] } +{ [BlockStatements] } It is a compile-time error for a record declaration to have more than one compact constructor declaration. @@ -4039,7 +4092,7 @@ The body of a compact constructor declaration must satisfy all of the following The body must not contain a return statement (§14.17). -The body must not contain an explicit constructor invocation statement (§8.8.7.1). +The body must not contain an explicit constructor invocation (§8.8.7.1). The body must not contain an assignment to a component field of the record class. diff --git a/chapter-9.txt b/chapter-9.txt index 493474f..1e91708 100644 --- a/chapter-9.txt +++ b/chapter-9.txt @@ -684,7 +684,7 @@ The following production from §4.3 is shown here for convenience: Dims: {Annotation} [ ] {{Annotation} [ ]} -By virtue of the grammar above, a method declaration in an annotation interface declaration cannot have formal parameters, type parameters, or a throws clause; and cannot be private, default, or static. Thus, an annotation interface cannot have the same variety of methods as a normal interface. Note that it is still possible for an annotation interface to inherit a default method from its implicit superinterface, java.lang.annotation.Annotation, though no such default method exists as of Java SE 24. +By virtue of the grammar above, a method declaration in an annotation interface declaration cannot have formal parameters, type parameters, or a throws clause; and cannot be private, default, or static. Thus, an annotation interface cannot have the same variety of methods as a normal interface. Note that it is still possible for an annotation interface to inherit a default method from its implicit superinterface, java.lang.annotation.Annotation, though no such default method exists as of Java SE 25. By convention, the only modifiers that should be present on the declaration of an annotation interface element are annotations. From a6b9939301f319be8bdc7192014b7561566dc6b1 Mon Sep 17 00:00:00 2001 From: YujiSoftware Date: Wed, 18 Mar 2026 20:09:42 +0900 Subject: [PATCH 2/3] Update Java SE 26 --- chapter-1.txt | 8 ++++---- chapter-12.txt | 12 ++++++------ chapter-13.txt | 2 +- chapter-14.txt | 4 ++-- chapter-15.txt | 14 +++++++++----- chapter-4.txt | 2 +- chapter-5.txt | 14 +++++++------- chapter-9.txt | 2 +- 8 files changed, 31 insertions(+), 27 deletions(-) diff --git a/chapter-1.txt b/chapter-1.txt index 9a9c364..fca87b9 100644 --- a/chapter-1.txt +++ b/chapter-1.txt @@ -18,7 +18,7 @@ The Java programming language is strongly and statically typed. This specificati The Java programming language is a relatively high-level language, in that details of the machine representation are not available through the language. It includes automatic storage management, typically using a garbage collector, to avoid the safety problems of explicit deallocation (as in C's free or C++'s delete). High-performance garbage-collected implementations can have bounded pauses to support systems programming and real-time applications. The language does not include any unsafe constructs, such as array accesses without index checking, since such unsafe constructs would cause a program to behave in an unspecified way. -The Java programming language is normally compiled to the bytecode instruction set and binary format defined in The Java Virtual Machine Specification, Java SE 25 Edition. +The Java programming language is normally compiled to the bytecode instruction set and binary format defined in The Java Virtual Machine Specification, Java SE 26 Edition. 1.1. Organization of the Specification @@ -113,7 +113,7 @@ Hello, world. Throughout this specification, we refer to classes and interfaces drawn from the Java SE Platform API. Whenever we refer to a class or interface (other than those declared in an example) using a single identifier N, the intended reference is to the class or interface named N in the package java.lang. We use the canonical name (§6.7) for classes or interfaces from packages other than java.lang. -A cross-reference within this specification is shown as (§x.y). Occasionally, we refer to concepts in the The Java Virtual Machine Specification, Java SE 25 Edition via cross-references of the form (JVMS §x.y). +A cross-reference within this specification is shown as (§x.y). Occasionally, we refer to concepts in the The Java Virtual Machine Specification, Java SE 26 Edition via cross-references of the form (JVMS §x.y). Non-normative text, designed to clarify the normative text of this specification, is given in smaller, indented text. @@ -191,7 +191,7 @@ The reference appears in an import declaration. 1.5.2. Current Preview Language Features -Java SE 25 defines one preview language feature: +Java SE 26 defines one preview language feature: Primitive Types in Patterns, instanceof, and switch @@ -228,4 +228,4 @@ Mitchell, James G., William Maybury, and Richard Sweet. The Mesa Programming Lan Stroustrup, Bjarne. The C++ Programming Language, 2nd ed. Addison-Wesley, Reading, Massachusetts, 1991, reprinted with corrections January 1994, ISBN 0-201-53992-6. -Unicode Consortium, The. The Unicode Standard, Version 16.0.0. South San Francisco: The Unicode Consortium, 2024. ISBN 978-1-936213-34-4. \ No newline at end of file +Unicode Consortium, The. The Unicode Standard, Version 17.0.0. South San Francisco: The Unicode Consortium, 2025. ISBN 978-1-936213-35-1. \ No newline at end of file diff --git a/chapter-12.txt b/chapter-12.txt index fb25a52..12c411f 100644 --- a/chapter-12.txt +++ b/chapter-12.txt @@ -34,7 +34,7 @@ The chapter continues with a specification of the procedures for creation of new The Java Virtual Machine starts execution by invoking a main method of some specified class or interface. If this method has a formal parameter, it is passed a single argument which is an array of strings. -The precise semantics of Java Virtual Machine startup are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 25 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. +The precise semantics of Java Virtual Machine startup are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 26 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. The manner in which the initial class or interface is specified to the Java Virtual Machine is beyond the scope of this specification, but it is typical, in host environments that use command lines, for the fully qualified name of the initial class or interface to be specified as a command line argument and for following command line arguments to be used as strings that are taken as the components of an array that is passed as an argument to the main method. If the original compilation unit was a compact compilation unit (§7.3), then the name of the file that contained the compilation unit, minus any extension, is typically used to specify the name of the initial class or interface. @@ -131,9 +131,9 @@ If there is no candidate main method to invoke, or if creating an instance of th Loading refers to the process of finding the binary form of a class or interface with a particular name, perhaps by computing it on the fly, but more typically by retrieving a binary representation previously computed from source code by a Java compiler, and constructing, from that binary form, a Class object to represent the class or interface (§1.4). -The precise semantics of loading are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 25 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. +The precise semantics of loading are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 26 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. -The binary representation of a class or interface is normally the class file format described in Chapter 4 of The Java Virtual Machine Specification, Java SE 25 Edition, but other representations are possible, provided they meet the requirements specified in §13.1. +The binary representation of a class or interface is normally the class file format described in Chapter 4 of The Java Virtual Machine Specification, Java SE 26 Edition, but other representations are possible, provided they meet the requirements specified in §13.1. 12.2.1. The Loading Process @@ -161,13 +161,13 @@ If a class loader L1 delegates loading of a class or interface C to another load A malicious class loader could violate these properties. However, it could not undermine the security of the type system, because the Java Virtual Machine guards against this. -For further discussion of these issues, see The Java Virtual Machine Specification, Java SE 25 Edition and the paper Dynamic Class Loading in the Java Virtual Machine, by Sheng Liang and Gilad Bracha, in Proceedings of OOPSLA '98, published as ACM SIGPLAN Notices, Volume 33, Number 10, October 1998, pages 36-44. A basic principle of the design of the Java programming language is that the run-time type system cannot be subverted by code written in the Java programming language, not even by implementations of sensitive system classes such as ClassLoader. +For further discussion of these issues, see The Java Virtual Machine Specification, Java SE 26 Edition and the paper Dynamic Class Loading in the Java Virtual Machine, by Sheng Liang and Gilad Bracha, in Proceedings of OOPSLA '98, published as ACM SIGPLAN Notices, Volume 33, Number 10, October 1998, pages 36-44. A basic principle of the design of the Java programming language is that the run-time type system cannot be subverted by code written in the Java programming language, not even by implementations of sensitive system classes such as ClassLoader. 12.3. Linking of Classes and Interfaces Linking is the process of taking a binary form of a class or interface and combining it into the run-time state of the Java Virtual Machine, so that it can be executed. A class or interface is always loaded before it is linked. -The precise semantics of linking are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 25 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. +The precise semantics of linking are given in Chapter 5 of The Java Virtual Machine Specification, Java SE 26 Edition. Here we present an overview of the process from the viewpoint of the Java programming language. Three different activities are involved in linking: verification, preparation, and resolution of symbolic references. @@ -541,7 +541,7 @@ Because the field three is initialized in the prologue of the Test constructor, 12.6. Finalization of Class Instances -As of Java SE 25, the Java SE Platform Specification allows finalization of class instances to be disabled in an implementation of the Java SE Platform, in anticipation of the removal of finalization from a future release of the Java SE Platform. +As of Java SE 26, the Java SE Platform Specification allows finalization of class instances to be disabled in an implementation of the Java SE Platform, in anticipation of the removal of finalization from a future release of the Java SE Platform. The class Object has a protected method called finalize; this method can be overridden by other classes. The particular definition of finalize that can be invoked for an object is called the finalizer of that object. Before the storage for an object is reclaimed by the garbage collector, the Java Virtual Machine will invoke the finalizer of that object. diff --git a/chapter-13.txt b/chapter-13.txt index 7393570..ba14aa3 100644 --- a/chapter-13.txt +++ b/chapter-13.txt @@ -78,7 +78,7 @@ This chapter first specifies some properties that any binary format for the Java 13.1. The Form of a Binary -Programs must be compiled either into the class file format specified by The Java Virtual Machine Specification, Java SE 25 Edition, or into a representation that can be mapped into that format by a class loader written in the Java programming language. +Programs must be compiled either into the class file format specified by The Java Virtual Machine Specification, Java SE 26 Edition, or into a representation that can be mapped into that format by a class loader written in the Java programming language. A class file corresponding to a class or interface declaration must have certain properties. A number of these properties are specifically chosen to support source code transformations that preserve binary compatibility. The required properties are: diff --git a/chapter-14.txt b/chapter-14.txt index 1a92b10..5896bb2 100644 --- a/chapter-14.txt +++ b/chapter-14.txt @@ -957,7 +957,7 @@ A set of case elements, P, covers a type T if one of the following cases applies P covers a type U where T and U have the same erasure. -P contains a pattern that is unconditional for T. +P contains a pattern that is unconditional for T (§14.30.3). T is a type variable with upper bound B and P covers B. @@ -1873,7 +1873,7 @@ It is a compile-time error if the return target of a return statement is a const It is a compile-time error if the return target of a return statement with value Expression is either a constructor, or a method that is declared void. -It is a compile-time error if the return target of a return statement with value Expression is a method with declared return type T, and the type of Expression is not assignable compatible (§5.2) with T. +It is a compile-time error if the return target of a return statement with value Expression is a method with declared return type T, and the type of Expression is not assignment compatible (§5.2) with T. Execution of a return statement with no value always completes abruptly, the reason being a return with no value. diff --git a/chapter-15.txt b/chapter-15.txt index 450651d..3b25954 100644 --- a/chapter-15.txt +++ b/chapter-15.txt @@ -258,7 +258,7 @@ Strict evaluation provides predictable results, but caused performance problems For compatibility, Java 1.2 allowed the programmer to forbid an implementation from using the extended-exponent value sets. The programmer expressed this by placing the strictfp modifier on the declaration of a class, interface, or method. strictfp constrained the floating-point semantics of any enclosed expressions to use the float value set for float expressions and the double value set for double expressions, ensuring the results of such expressions were fully predictable. Code modified by strictfp thus had the same floating-point semantics as specified in Java 1.0 and 1.1. -In Java SE 17 and later, the Java SE Platform always requires strict evaluation of floating-point expressions. Newer members of the processor families that had performance problems implementing strict evaluation no longer have that difficulty. This specification no longer associates float and double with the four value sets described above, and the strictfp modifier no longer affects the evaluation of floating-point expressions. For compatibility, strictfp remains a keyword in Java SE 25 (§3.8) and continues to have restrictions on its use (§8.4.3, §9.4), although Java compilers are encouraged to warn the programmer about its obsolete status. Future versions of the Java programming language may redefine or remove the strictfp keyword. +In Java SE 17 and later, the Java SE Platform always requires strict evaluation of floating-point expressions. Newer members of the processor families that had performance problems implementing strict evaluation no longer have that difficulty. This specification no longer associates float and double with the four value sets described above, and the strictfp modifier no longer affects the evaluation of floating-point expressions. For compatibility, strictfp remains a keyword in Java SE 26 (§3.8) and continues to have restrictions on its use (§8.4.3, §9.4), although Java compilers are encouraged to warn the programmer about its obsolete status. Future versions of the Java programming language may redefine or remove the strictfp keyword. 15.5. Expressions and Run-Time Checks @@ -2320,13 +2320,17 @@ If the form is super . [TypeArguments] Identifier, then: It is a compile-time error if the compile-time declaration is abstract. -It is a compile-time error if the method invocation occurs in a static context or in an early construction context of the current class. +It is a compile-time error if the method invocation occurs in a static context. + +It is a compile-time error if the method invocation occurs in an early construction context of the current class. If the form is TypeName . super . [TypeArguments] Identifier, then: It is a compile-time error if the compile-time declaration is abstract. -It is a compile-time error if the method invocation occurs in a static context or in an early construction context of the current class. +It is a compile-time error if the method invocation occurs in a static context. + +It is a compile-time error if the method invocation occurs in an early construction context of the class named by TypeName. If TypeName denotes a class C, then if the class or interface declaration immediately enclosing the method invocation is not C or an inner class of C, a compile-time error occurs. @@ -2535,7 +2539,7 @@ Otherwise, an instance method is to be invoked and there is a target reference. If the invocation mode is super, overriding is not allowed. Method m of class or interface C is the one to be invoked. If m is abstract, an AbstractMethodError is thrown. -Otherwise, if the invocation mode is virtual, and Q and m jointly indicate a signature polymorphic method (§15.12.3), then the target object is an instance of java.lang.invoke.MethodHandle or java.lang.invoke.VarHandle. The target object encapsulates state which is matched against the information associated with the method invocation at compile time. Details of this matching are given in The Java Virtual Machine Specification, Java SE 25 Edition and the Java SE Platform API. If matching succeeds, then either the method referenced by the java.lang.invoke.MethodHandle instance is directly and immediately invoked, or the variable represented by the java.lang.invoke.VarHandle instance is directly and immediately accessed, and in either case the procedure in §15.12.4.5 is not executed. If matching fails, then a java.lang.invoke.WrongMethodTypeException is thrown. +Otherwise, if the invocation mode is virtual, and Q and m jointly indicate a signature polymorphic method (§15.12.3), then the target object is an instance of java.lang.invoke.MethodHandle or java.lang.invoke.VarHandle. The target object encapsulates state which is matched against the information associated with the method invocation at compile time. Details of this matching are given in The Java Virtual Machine Specification, Java SE 26 Edition and the Java SE Platform API. If matching succeeds, then either the method referenced by the java.lang.invoke.MethodHandle instance is directly and immediately invoked, or the variable represented by the java.lang.invoke.VarHandle instance is directly and immediately accessed, and in either case the procedure in §15.12.4.5 is not executed. If matching fails, then a java.lang.invoke.WrongMethodTypeException is thrown. Otherwise, the invocation mode is interface or virtual. @@ -2565,7 +2569,7 @@ If the method to be invoked is default, and more than one default method appears If the invocation mode is interface and the method to be invoked is neither public nor private, an IllegalAccessError is thrown. -The above procedure (if it terminates without error) will find a non-abstract, accessible method to invoke, provided that all classes and interfaces in the program have been consistently compiled. However, if this is not the case, then various errors may occur, as specified above; additional details about the behavior of the Java Virtual Machine under these circumstances are given by The Java Virtual Machine Specification, Java SE 25 Edition. +The above procedure (if it terminates without error) will find a non-abstract, accessible method to invoke, provided that all classes and interfaces in the program have been consistently compiled. However, if this is not the case, then various errors may occur, as specified above; additional details about the behavior of the Java Virtual Machine under these circumstances are given by The Java Virtual Machine Specification, Java SE 26 Edition. The dynamic lookup process, while described here explicitly, will often be implemented implicitly, for example as a side-effect of the construction and use of per-class method dispatch tables, or the construction of other per-class structures used for efficient dispatch. diff --git a/chapter-4.txt b/chapter-4.txt index 68e192a..f634aed 100644 --- a/chapter-4.txt +++ b/chapter-4.txt @@ -1767,7 +1767,7 @@ The correspondence between compile-time types and run-time types is incomplete f At run time, classes and interfaces are loaded by the Java Virtual Machine using class loaders. Each class loader defines its own set of classes and interfaces. As a result, it is possible for two loaders to load an identical class or interface definition but produce distinct classes or interfaces at run time. Consequently, code that compiled correctly may fail at link time if the class loaders that load it are inconsistent. -See the paper Dynamic Class Loading in the Java Virtual Machine, by Sheng Liang and Gilad Bracha, in Proceedings of OOPSLA '98, published as ACM SIGPLAN Notices, Volume 33, Number 10, October 1998, pages 36-44, and The Java Virtual Machine Specification, Java SE 25 Edition for more details. +See the paper Dynamic Class Loading in the Java Virtual Machine, by Sheng Liang and Gilad Bracha, in Proceedings of OOPSLA '98, published as ACM SIGPLAN Notices, Volume 33, Number 10, October 1998, pages 36-44, and The Java Virtual Machine Specification, Java SE 26 Edition for more details. Type variables (§4.4) and type arguments (§4.5.1) are not reified at run time. As a result, the same class or interface at run time represents multiple parameterized types (§4.5) from compile time. Specifically, all compile-time parameterizations of a given generic type (§8.1.2, §9.1.2) share a single run-time representation. diff --git a/chapter-5.txt b/chapter-5.txt index 2cc127a..42cc37b 100644 --- a/chapter-5.txt +++ b/chapter-5.txt @@ -74,11 +74,11 @@ String conversions There are seven kinds of conversion contexts in which poly expressions may be influenced by context or implicit conversions may occur. Each kind of context has different rules for poly expression typing and allows conversions in some of the categories above but not others. The contexts are: -Assignment contexts (§5.2, §15.26), in which an expression's value is bound to a named variable. Primitive and reference types are subject to widening, values may be boxed or unboxed, and some primitive constant expressions may be subject to narrowing. An unchecked conversion may also occur. +Assignment contexts (§5.2, §15.26), in which an expression's value is assigned to a named variable. Primitive and reference types are subject to widening, values may be boxed or unboxed, and some primitive constant expressions may be subject to narrowing. An unchecked conversion may also occur. -Strict invocation contexts (§5.3, §15.9, §15.12), in which an argument is bound to a formal parameter of a constructor or method. Widening primitive, widening reference, and unchecked conversions may occur. +Strict invocation contexts (§5.3, §15.9, §15.12), in which an argument is assigned to a formal parameter of a constructor or method. Widening primitive, widening reference, and unchecked conversions may occur. -Loose invocation contexts (§5.3, §15.9, §15.12), in which, like strict invocation contexts, an argument is bound to a formal parameter. Method or constructor invocations may provide this context if no applicable declaration can be found using only strict invocation contexts. In addition to widening and unchecked conversions, this context allows boxing and unboxing conversions to occur. +Loose invocation contexts (§5.3, §15.9, §15.12), in which, like strict invocation contexts, an argument is assigned to a formal parameter. Method or constructor invocations may provide this context if no applicable declaration can be found using only strict invocation contexts. In addition to widening and unchecked conversions, this context allows boxing and unboxing conversions to occur. String contexts (§5.4, §15.18.1), in which a value of any type is converted to an object of type String. @@ -88,7 +88,7 @@ Numeric contexts (§5.6), in which the operands of a numeric operator or some ot Testing contexts (§5.7), in which an expression's value is converted to a type explicitly specified by a pattern (§14.30). Testing contexts are more inclusive than assignment or loose invocation contexts, but not as inclusive as casting contexts. -The term "conversion" is also used to describe, without being specific, any conversions allowed in a particular context. For example, we say that an expression that is the initializer of a local variable is subject to "assignment conversion", meaning that a specific conversion will be implicitly chosen for that expression according to the rules for the assignment context. As another example, we say that an expression undergoes "casting conversion" to mean that the expression's type will be converted as permitted in a casting context. +The term "conversion" is also used to describe, without being specific, any conversions allowed in a particular context. For example, we say that an expression that is the initializer of a local variable is subject to "assignment conversion", meaning that a specific conversion will be implicitly chosen for that expression according to the rules for the assignment context. As another example, we say that an expression undergoes "casting conversion" to mean that the expression's value will be converted as permitted in a casting context. Example 5.0-2. Conversions In Various Contexts @@ -1010,7 +1010,7 @@ The target type in these contexts is always String, and a string conversion (§5 5.5. Casting Contexts -Casting contexts allow the operand of a cast expression (§15.16) to be converted to the type explicitly named by the cast operator. Compared to assignment contexts and invocation contexts, casting contexts allow the use of more of the conversions defined in §5.1, and allow more combinations of those conversions. +Casting contexts allow the operand of a cast expression (§15.16) to be converted to the type explicitly specified by the cast operator. Compared to assignment contexts and invocation contexts, casting contexts allow the use of more of the conversions defined in §5.1, and allow more combinations of those conversions. If the expression is of a primitive type, then a casting context allows the use of one of the following: @@ -1365,8 +1365,6 @@ The example converts the ASCII character G to the ASCII control-G (BEL), by mask Testing contexts allow the operand of a pattern match operator (§15.20.2), or the selector expression of a switch expression or statement that has at least one pattern case label associated with its switch block (§14.11.1) to be converted to a type as part of the process of pattern matching. As pattern matching is an inherently conditional process (§14.30.2), it is expected that a testing context will make use of conversions that may fail at run time. -Testing contexts use similar conversions for reference types as casting contexts except that they do not permit narrowing reference conversions that are unchecked (§5.1.6.2). - If the expression is of a primitive type, then a testing context allows the use of an identity conversion (§5.1.1). If the expression is of a reference type, then a testing context allows the use of one of the following: @@ -1377,6 +1375,8 @@ a widening reference conversion (§5.1.5) a narrowing reference conversion that is checked (§5.1.6.2) +Unlike casting contexts, testing contexts do not permit narrowing reference conversions that are unchecked. + If the expression has the null type, then the expression may be converted to any reference type. If a testing context makes use of a narrowing reference conversion, then a run time check will be performed on the class of the expression's value, possibly causing a ClassCastException. Otherwise, no run time check is performed. \ No newline at end of file diff --git a/chapter-9.txt b/chapter-9.txt index 1e91708..1c4de56 100644 --- a/chapter-9.txt +++ b/chapter-9.txt @@ -684,7 +684,7 @@ The following production from §4.3 is shown here for convenience: Dims: {Annotation} [ ] {{Annotation} [ ]} -By virtue of the grammar above, a method declaration in an annotation interface declaration cannot have formal parameters, type parameters, or a throws clause; and cannot be private, default, or static. Thus, an annotation interface cannot have the same variety of methods as a normal interface. Note that it is still possible for an annotation interface to inherit a default method from its implicit superinterface, java.lang.annotation.Annotation, though no such default method exists as of Java SE 25. +By virtue of the grammar above, a method declaration in an annotation interface declaration cannot have formal parameters, type parameters, or a throws clause; and cannot be private, default, or static. Thus, an annotation interface cannot have the same variety of methods as a normal interface. Note that it is still possible for an annotation interface to inherit a default method from its implicit superinterface, java.lang.annotation.Annotation, though no such default method exists as of Java SE 26. By convention, the only modifiers that should be present on the declaration of an annotation interface element are annotations. From 26dffc62070b4dd69c032c3c8a39ae8b54324fe7 Mon Sep 17 00:00:00 2001 From: YujiSoftware Date: Wed, 18 Mar 2026 20:10:18 +0900 Subject: [PATCH 3/3] Added diff to README.md --- README.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/README.md b/README.md index 1f4106e..1930ea4 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,25 @@ # The Java Language Specification diffs This repository can display the differences between various versions of the [Java Language specification](https://docs.oracle.com/javase/specs/index.html). + +* [Java 7 .. 8](https://github.com/YujiSoftware/java_sepc_diff/compare/java7...java8?w=1) +* [Java 8 .. 9](https://github.com/YujiSoftware/java_sepc_diff/compare/java8...java9?w=1) +* [Java 9 .. 10](https://github.com/YujiSoftware/java_sepc_diff/compare/java9...java10?w=1) +* [Java 10 .. 11](https://github.com/YujiSoftware/java_sepc_diff/compare/java10...java11?w=1) +* [Java 11 .. 12](https://github.com/YujiSoftware/java_sepc_diff/compare/java11...java12?w=1) +* [Java 12 .. 13](https://github.com/YujiSoftware/java_sepc_diff/compare/java12...java13?w=1) +* [Java 13 .. 14](https://github.com/YujiSoftware/java_sepc_diff/compare/java13...java14?w=1) +* [Java 14 .. 15](https://github.com/YujiSoftware/java_sepc_diff/compare/java14...java15?w=1) +* [Java 15 .. 16](https://github.com/YujiSoftware/java_sepc_diff/compare/java15...java16?w=1) +* [Java 16 .. 17](https://github.com/YujiSoftware/java_sepc_diff/compare/java16...java17?w=1) +* [Java 17 .. 18](https://github.com/YujiSoftware/java_sepc_diff/compare/java17...java18?w=1) +* [Java 18 .. 19](https://github.com/YujiSoftware/java_sepc_diff/compare/java18...java19?w=1) +* [Java 19 .. 20](https://github.com/YujiSoftware/java_sepc_diff/compare/java19...java20?w=1) +* [Java 20 .. 21](https://github.com/YujiSoftware/java_sepc_diff/compare/java20...java21?w=1) +* [Java 21 .. 22](https://github.com/YujiSoftware/java_sepc_diff/compare/java21...java22?w=1) +* [Java 22 .. 23](https://github.com/YujiSoftware/java_sepc_diff/compare/java22...java23?w=1) +* [Java 23 .. 24](https://github.com/YujiSoftware/java_sepc_diff/compare/java23...java24?w=1) +* [Java 24 .. 25](https://github.com/YujiSoftware/java_sepc_diff/compare/java24...java25?w=1) +* [Java 25 .. 26](https://github.com/YujiSoftware/java_sepc_diff/compare/java25...java26?w=1) + +→ [The Java Virtual Machine Specification diffs](https://github.com/YujiSoftware/jvm_sepc_diff)