JavaSoft  java.sun.com - The Source for Java java.sun.com - The Source for JavaFeedbackMapSearch
Clarifications and Amendments to
The Java Language Specification



The Java programming language has evolved since the publication of  the The Java Language Specification.
Here is a brief overview of changes made to the Java platform in JDK 1.1(Originally published as
                   Appendix D from The Java Programming Language by Ken Arnold).

The most significant language change has been  the addition of nested classes (often called inner classes).  For more comprehensive details, see the nested classes specification.

In addition, various questions have arisen over time with respect to The Java Language Specification. This has prompted us to issue a series of clarifications and amendments to the specification, given below. We will be issuing amendments on an ongoing basis, as the need arises.

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


Package Naming Conventions

JLS 7.7 discusses recommended conventions for package names and states that the first component of a unique package name should be written in uppercase letters. This is no longer the recommended convention. The relevant text should be revised to state:

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 identifyingcountries as specified in ISO Standard 3166, 1981.
 
 

Interface Member Modifiers

Several grammar productions were inadvertently omitted from section 9.3 of the JLS, which discusses modifiers on members of interfaces. The beginning of JLS 9.3 should be corrected to read:
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.

Resolution of Symbolic References

In JLS 12.3.3 the bullets discussing NoSuchFieldError and NoSuchMethodError should be amended by omitting the restriction that the declaration of the field or method must be local to class and may not be an inherited field or method.

Class finalization

Class finalization (JLS 12.7) has been removed from the Java language. The functionality of JLS 12.7 is subsumed by instance finalization (JLS 12.6). Here is a rationale for this decision.

Class Unloading

Questions have arisen with respect to the interpretation of JLS 12.8 "Unloading of Classes and Interfaces". The following statement should help clarify the issue:

 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.

null is a Compile time Constant

JLS 15.27 defines the notion of a compile time constant. The definition erroneously excludes null. The beginning of JLS 15.27 should read:
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

java.lang.Object hashCode()

The first sentence of the first bullet of JLS 20.1.4 should be amended as follows:
Whenever it is invoked on the same object more than once during an execution of a Java application, hashCode must consistently return the same integer, provided no information used in equals comparisons on the object is modified.

Java.lang.Class.forName()

JLS 20.3.8 should state that a call to java.lang.Class.forName("X") causes the class named "X" to be initialized.

java.lang.Double and java.lang.Float valueOf()

The JLS disallows trailing d,D,f or F as arguments to the conversion routines Double.valueOf() and Float.valueOf(). However, these forms have been allowed by some implementations for some time. Modifying the specification makes the rules more uniform and preserves compatibility with all existing Java programs.

The lexical syntax rule and the surrounding text in both JLS 20.9.17 and 20.10.16 should read:

The rest of s should constitute a FloatValue as described by the lexical rule:

FloatValue:

  Sign_opt FloatingPointLiteral
where Sign and FloatingPointLiteral are as defined in section 3.10.2.

The final paragraph in both sections will be deleted as well.

Positive and Negative Infinity

JLS 20.10.22 contains a typographical error. It should define positive infinity as 0x7ff0000000000000L and negative infinity as 0xfff0000000000000L.

The Java Virtual Machine Specification 4.4.5 contains the same typos.

java.lang.String hashCode()

The String hash function implemented in JDK releases through 1.1.3 did not match the function specified in the first edition of the Java Language Specification (JLS 20.12.10). The specified function is not implementable. It addresses characters outside of the input string. Additionally, the implemented function performed very poorly on certain classes of strings, including URLs. (The poor performance is due to the "sampling" nature of the function for strings over 15 characters.)

To bring the implementation into accord with the specification and to fix the performance problems, we are modifying the specification and implementation in tandem. The new String hash function as of JDK1.2 is specified to be:

s[0] * 31^(n-1) + s[1] * 31^(n-2) + ... + s[n-1]

where s[i] is the ith character of string s.

This change should not have an effect on the majority of Java applications. If an application has persistent data that depends on actual String hash values, it could theoretically be affected. The serialized representation of a Hashtable does NOT depend on the actual hash values of the keys stored in the Hashtable. Thus, applications relying on serialization for storage of persistent data will not be affected.

java.lang.Runtime freeMemory()

JLS section 20.16.8 can be clarified by omitting the sentence:
This value is always less than the current value returned by the totalMemory method
This does not change the meaning in any way, but eliminates potential misunderstandings.

java.lang.Thread yield()

JLS section 20.20.38 should read:

The method causes the current thread to yield, allowing the thread scheduler to choose a runnable thread (possibly the thread that is yielding) for execution.

This does not change the meaning in any way, but eliminates potential misunderstandings. The revised wording makes it clear that even if other runnable threads are available, there is no guarantee that they will be run rather than the thread which calls yield().

java.util.Dictionary

JLS 21.4.3 contains a typographical error. The first line begins with the text
The general contract for the isEmpty method ...
whereas the text should read

The general contact for the get method ...

java.util.Random

JLS 21.9.8 - 21.9.12 contain typographical errors. The description of the method implementation in each of these sections first begins with the text

The method setSeed is implemented ...
                     ^

The text should give the name of the appropriate method for each section.

java.io.File, java.io.FileInputStream and caching

File systems may implement caching schemes, but these should be transparent to users of Java. The description of java.io.File (JLS 22.4) and/or java.io.FileInputStream (JLS 22.24) should be clarified by stating this explicitly.

Constructing java.io.RandomAccessFiles

Section 22.23.1 of the JLS does not clearly specify the full behavior of the RandomAccessFile constructor if the file does not yet exist. It should state that the file is created if it does not exist and the mode is "rw"; if the mode is "r" and the file does not exist, a FileNotFoundException will be thrown.

java.io.RandomAccessFile.seek()

The method java.io.RandomAccessFile.seek() (JLS 22.23.5) does not raise an exception if set beyond the end of the file. The operation succeeds (but leaves the length of the file unchanged).

java.io.File.list()

JLS 22.24.26 should state that if filter is null, all names in the directory are returned.
 
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