The most significant language change has been:

1. The addition of nested classes (often called inner classes).  For more comprehensive details, see the nested classes specification. The nested classes specification has itself required these clarifications over time.
2. The changes to floating point semantics. Those sections of the JLS (1st edition) that have been affected by the floating point changes are listed here (in PDF format). Changes are highlighted using change bars.

Please send any technical remarks you might have to jls@java.sun.com. We look forward to your comments. 

Package Naming Conventions

The first component of a unique package name is always written in all-lowercase ASCII letters and should be one of
the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981.
 
 

Interface Member Modifiers

ConstantDeclaration:

  ConstantModifiers_opt Type VariableDeclarator



ConstantModifiers:

  ConstantModifier

  ConstantModifier ConstantModifiers



ConstantModifier: one of

  public static final

Every field declaration in the body of an interface is implicitly public,static, and final. It is permitted, but strongly discouraged as a matter of style, to redundantly specify any or all of these modifiers for such fields. It is a compile time error if the same modifier appears more than once in a field declaration.

Arrays implement java.io.Serializable

Preparation does not cause AbstractMethodErrors

Preparation involves creating the static fields (class variables and constants) for a class or interface and initializing such fields to the standard default values (§4.5.4). This does not require the execution of any Java code; explicit initializers for static fields are executed as part of initialization (§12.4), not preparation.

Implementations of the Java Virtual Machine may precompute additional data structures at preparation time in order to make later operations on a class or interface more efficient. One particularly useful data structure is a "method table" or other data structure that allows any method to be invoked on instances of a class without requiring a search of superclasses at invocation time.

Resolution of Symbolic References

Class Initialization

Initialization of a class consists of executing its static initializers  and the initializers for static fields declared in the class. Initialization of an interface consists of executing the initializers for fields declared in the interface.

Before a class is initialized, its direct superclass must be initialized, but interfaces implemented by the class need not be initialized. Similarly, the superinterfaces of an interface need not be initialized before the interface is initialized.

A class or interface type T will be initialized immediately before the first occurence of any one of the following:

• T is a class and an instance of T is created.
• T is a class and a static method of T is invoked.
• A non-constant static field of T is used or assigned. A constant field is one that is (explicitly or implicitly) both final and static, and that is initialized with the value of a compile-time constant expression. A reference to such a field must be resolved at compile time to a copy of the compile-time constant value, so uses of such a field never cause initialization.

Invocation of certain reflective methods in class java.lang.Class and in package java.lang.reflect also causes class or interface initialization.

Class finalization

Class Unloading

 A class or interface may be unloaded if and only if its class loader is unreachable (the definition of unreachable is given in JLS 12.6.1). Classes loaded by the bootstrap loader may not be unloaded.

Here is a brief technical rationale for this statement.
 

Compilation of Symbolic References

The third bullet of JLS 13.1 should be corrected to state the following:

Given a legal field access expression in a class C referencing a field f declared in another class:
If the expression is of the form

Primary.f

then let T be the type of Primary. T must be some reference type denoting a class or interface.

If the expression is of the form

super.f

then let T be the superclass of C.
 

The reference to f must be compiled into a symbolic reference to the class or interface T, plus the simple name of the field, f. The reference must also include a symbolic reference to the declared type of the field so that the verifier can check that the type is as expected. References to fields that are static, final, and initialized with compile-time constant expressions are resolved at compile time to the constant value that is denoted. No reference to such a constant field should be present in the code in a binary file (except in the class or interface containing the constant field, which will have code to initialize it), and such constant fields must always appear to have been initialized; the default initial value for the type of such a field must never be observed. See §13.4.8 for a discussion.

Similarly, the fourth bullet of JLS 13.1 should be corrected as follows:

Given a method invocation expression in a class C referencing a method m declared in another class:
If the expression is of the form

Primary.m

then let T be the type of Primary. T must be some reference type denoting a class or interface.

If the expression is of the form

super.f

then let T be the superclass of C.

If the expression is of the form

X.m

then X must be the name of a class or interface. Let T be the class or interface denoted by X.
 

The reference to a method or constructor must be resolved at compile time to a symbolic reference to T, plus the signature of the method or constructor.  A reference to a method must also include either a symbolic reference to the return type of the denoted method or an indication that the denoted method is declared void and does not return a value.

Here is an explanation why these corrections are necessary.

Obviously, much of JLS 13.4.5 must change in light of the changes to JLS 13.1 and 12.3.3.

Final Fields and Binary Compatibility

Suppose that a new version of class Super  is produced:

class Super {final static char s = 'b'; }

If Super is recompiled but not Test, then running the new binary with the existing binary of Test results in an IllegalAccessError.

Volatile Fields and Binary Compatibility

Corrrected Method Lookup Algorithm

The dynamic method lookup uses the following procedure to search class S, and then the superclasses of class S, as necessary, for method m.
Let X be the type of the target reference of the method invocation.

If class S contains a declaration for a non-abstract method named m with the same descriptor (same number of parameters, the same parameter types, and the same return type) required by the method invocation as determined at compile time (§15.11.3), then :

• If the invocation mode is super or interface, then this is the method to be invoked, and then procedure terminates.
• If the invocation mode is virtual, and the declaration in S overrides (§8.4.6.1) X.m, then this is the method to be invoked, and the procedure terminates.
• Otherwise, if S has a superclass, this same lookup procedure is performed recursively using the direct superclass of S in place of S; the method to be invoked is the result of the recursive invocation of this lookup procedure.
• Otherwise, an AbstractMethodError is raised.

null is a Compile time Constant

A compile-time constant expression is an expression denoting a value of primitive type or null or a String that is composed using only the following:

* Literals of primitive type, null and literals of type String

This page was updated: Monday, 04-May-1998 14:01:22 PDT What's New | Read | Products | Applets | For Developers Real World Java | Business | Marketing | Employment | Java Store FEEDBACK | SUPPORT & SERVICES | MAP For information, call: (888) 843-5282 (North America) (512) 434-1591 (Other locations) Copyright © 1995-98 Sun Microsystems, Inc. All Rights Reserved. Legal Terms. Privacy Policy.