[r6rs-discuss] unspecified or undefined behaviors in Java
William D Clinger
will at ccs.neu.edu
Wed Mar 25 18:55:43 EDT 2009
John Cowan described an alternative universe:
> ES 3.1 is attempting to reach the stage where there is no *explicitly*
> undefined behavior. The same is true of Java....
Attempting, perhaps, but not succeeding. In what follows, JLS
means the Java Language Specification, Third Edition .
JLS 15.4 explicitly says that "some leeway is granted for an
implementation to use an extended exponent range to represent
intermediate results; the net effect, roughly speaking, is that
a calculation might produce "the correct answer" in situations
where exclusive use of the float value set or double value set
might result in overflow or underflow."
JLS 12.6.2 explicitly says that Java "imposes no ordering on
finalize method calls. Finalizers may be called in any order,
or even concurrently." JLS 12.6.1 describes optimizations
that implementations are permitted but not required to perform
that may cause a finalizer to be invoked "earlier than might
be otherwise expected."
JLS 17.4 explicitly says its highly nondeterministic memory
model "describes possible behaviors of a program. An
implementation is free to produce any code it likes, so long
as all resulting executions of a program produce a result
that can be predicted by the memory model." JLS 17.4.3
explicitly notes that Java's memory model does not guarantee
sequential consistency for programs in general; it guarantees
sequential consistency only for programs that do not have data
JLS 17.5.3 explicitly says that "Final fields can be changed
via reflection and other implementation dependent means. The
only pattern in which this has reasonable semantics is one..."
that is not enforced by Java. Furthermore "If a final field
is initialized to a compile-time constant in the field
declaration, changes to the final field may not be observed,
since uses of that final field are replaced at compile time
with the compile-time constant." Et cetera.
Several aspects of Java's standard libaries are explicitly
undefined or implementation-dependent. For example, the
specification of ConcurrentModificationException (which is
somewhat misleading, because that exception can be thrown
even by sequential, single-threaded programs) explicitly
states that "the results of the iteration are undefined
under" certain circumstances, and describes circumstances
under which "the object may throw this exception" but does
not have to.
Finally, the behaviors of Java's GUI libraries have been
notoriously implementation-dependent because some systems
implement them via polling, some via green threads, and
some via concurrency.
For several of the above issues, notably floating point
and the memory model, the designers of Java originally
attempted to specify a semantics that gave insufficient
leeway to implementations. That is why the semantics of
floating point and of the Java memory model have changed
 Guy L Steele Jr. The Java Language Specification,
Third Edition. Online at
More information about the r6rs-discuss