The Mozilla Organization
	At A Glance
	Feedback
	Get Involved
	Newsgroups
	License Terms
	Newsbot

Developer Docs
	Roadmap
	Projects
	Ports
	Module Owners
	Hacking
	Get the Source
	Build It

Testing
	Download
	Bugzilla
	Bug Writing

Tools
	View Source
	Tree Status
	New Checkins
	Submit A Bug

FAQ
Search

Requirements and Limitations

Requirements

Rhino requires version 1.1 or greater of Java.

To use the JavaAdapter feature, Rhino must be running under a security manager that allows the definition of class loaders.

Limitations

Platforms and JITs

Versions of the Symantec JIT prior to 3.00.029(i) will report internal errors for some generated class files.

Versions of the Microsoft Command-line Loader for Java (jview.exe) prior to 4.79.2613 will fail on some classes generated with higher debug levels.

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.