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 [1]. 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 races. 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 over time. Will [1] Guy L Steele Jr. The Java Language Specification, Third Edition. Online at http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
