pjs/js/rhino/docs/limits.html

87 строки
3.6 KiB
HTML

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Norris Boyd">
<meta name="GENERATOR" content="Mozilla/4.72 [en]C-NSCP (WinNT; U) [Netscape]">
<title>JavaScript Requirements and Limitations</title>
</head>
<body bgcolor="#FFFFFF">
<center>
<h1>
Requirements and Limitations</h1></center>
<h2>
<b>Requirements</b></h2>
Rhino requires version 1.1 or greater of Java.
<p>To use the JavaAdapter feature or an optimization level of 0 or greater,
Rhino must be running under a security manager that allows the definition
of class loaders.
<p>
<hr WIDTH="100%">
<h2>
<b>Limitations</b></h2>
<h3>
<b>Platforms and </b>JITs</h3>
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.
<p>Windows versions of the Symantec JIT prior to 3.00.029(i) will report
internal errors for some generated class files.
<p>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
<tt>java.io.File.separatorChar</tt> before <tt>java.io.File</tt>
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.)
<p>The AIX Java version "JDK 1.1.6 IBM build a116-19980924 (JIT enabled:
jitc)" core dumps running several classes generated by Rhino. It also has
errors in java.lang.Math.pow that are reflected as failures in the JavaScript
Math object's pow method.
<p>IBM Java for Linux version "JDK 1.1.8 IBM build l118-19991013 (JIT enabled:
jitc)" has errors in java.lang.Math.pow that are reflected as test failures
in the JavaScript Math object's pow method.
<p>Solaris JDK 1.1.6 has errors in java.lang.Math.atan2 that are reflected
as test failures in the JavaScript Math object's atan2 method.
<br>&nbsp;
<h3>
<b>LiveConnect</b></h3>
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:
<blockquote><tt>javaObj.fieldAndMethod = 5;</tt>
<br><tt>var field = javaObj.fieldAndMethod;</tt>
<br><tt>javaObj.fieldAndMethod = 7;</tt>
<br><tt>// now, field == 7</tt></blockquote>
You can work around this by forcing the field value to be converted to
a JavaScript type when you take its value:
<blockquote><tt>javaObj.fieldAndMethod = 5;</tt>
<br><tt>var field = javaObj.fieldAndMethod + 0; // force conversion now</tt>
<br><tt>javaObj.fieldAndMethod = 7;</tt>
<br><tt>// now, field == 5</tt></blockquote>
<h3>
<b>JSObject</b></h3>
Rhino does NOT support the <tt>netscape.javascript.JSObject</tt> class.
<br>&nbsp;
<h3>
<b>Date object</b></h3>
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.
<p>Under the 1.1.6 JRE, evaluating <tt>(new Date(1998, 9, 25, 2)).toString()</tt>
returns:
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sun Oct 25 02:00:00 GMT-0800 (PST) 1998</pre>
Earlier versions may return:
<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sun Oct 25 02:00:00 GMT-0700 (PDT) 1998</pre>
(the JRE doesn't report the changeover until Nov. 1.)
<p>The Microsoft SDK 3.1 for Java also exhibits this problem.
<p>
<hr WIDTH="100%">
<br><a href="rhino.html">back to top</a>
</body>
</html>