Many platforms and JREs have problems converting decimal numbers to and from strings. These errors are usually boundary case errors and will show up as test failures in section 7.7.3.

On the Symantec JIT and the AIX JVM, accessing a static field of a class that has not yet loaded may not give the correct value of the field. For example, accessing java.io.File.separatorChar before java.io.File has been loaded will return a value of 0. (This is a bug in the JIT; accessing the field should cause the class to be loaded.)

LiveConnect

If a JavaObject's field's name collides with that of a method, the value of that field is retrieved lazily, and can be counter-intuitively affected by later assignments:

javaObj.fieldAndMethod = 5;
var field = javaObj.fieldAndMethod;
javaObj.fieldAndMethod = 7;
// now, field == 7

You can work around this by forcing the field value to be converted to a JavaScript type when you take its value:

javaObj.fieldAndMethod = 5;
var field = javaObj.fieldAndMethod + 0; // force conversion now
javaObj.fieldAndMethod = 7;
// now, field == 5

JSObject

JavaScript 1.4 for Java will NOT support the netscape.javascript.JSObject class.

Date object

The JavaScript Date object depends on time facilities of the underlying Java runtime to determine daylight savings time dates. Earlier JRE versions may report a date for the daylight savings changeover that is a week off. JRE 1.1.6 reports the correct date.

Under the 1.1.6 JRE, evaluating (new Date(1998, 9, 25, 2)).toString() returns:

        Sun Oct 25 02:00:00 GMT-0800 (PST) 1998

Earlier versions may return:

        Sun Oct 25 02:00:00 GMT-0700 (PDT) 1998

(the JRE doesn't report the changeover until Nov. 1.)

The Microsoft SDK 3.1 for Java also exhibits this problem.