Rhino allows to pass a JavaScript function to a Java method expecting an interface which either has a single method or all its methods have the same number of parameters and each corresponding parameter has the same type.
The JavaScript function will be called whenever interface's method is called from Java. The function will receive all Java arguments properly converted into JS types and as the last parameter Rhino will pass interface method's name.
Rhino fully supports <tt>uneval()</tt> function and <tt>toSource()</tt> method which are extensions to ECMAScript available in <ahref="http://www.mozilla.org/js/">SpiderMonkey</a>. They return a string that can be passed to the <tt>eval()</tt> function to reconstruct the original value when possible. It is guaranteed that <tt>uneval(eval(uneval(x))) == uneval(x)</tt> and in many cases more useful notion <tt>eval(uneval(x)) == deep_copy_of_x</tt> holds.
Rhino supports <tt>seal(object)</tt> function which is another ECMAScript extension from SpiderMonkey. The function makes the object immune to changes and any attempt to add, modify or delete a property of such object will throw an exception. Previously sealing was only possible through the Java <tt>sealObject()</tt> method in <tt>org.mozilla.javascript.ScriptableObject</tt> and before Rhino 1.5R5 it was possible to modify existing properties of sealed objects.
In Rhino 1.5R5 all exceptions generated during execution of a script provide information about script's source name and line number that triggered the exception. The exception class <tt>org.mozilla.javascript.JavaScriptException</tt> is used now only to represent exceptions explicitly thrown by the JavaScript <b>throw</b> statement, it never wraps exceptions thrown in a Java method invoked by the script. Such exceptions are always wrapped as <tt>org.mozilla.javascript.WrappedException</tt>.
</p>
<p>
See <ahref="http://bugzilla.mozilla.org/show_bug.cgi?id=217584">Bugzilla 217584</a>, <ahref="http://bugzilla.mozilla.org/show_bug.cgi?id=219055">Bugzilla 219055</a>
Previously Rhino required a scope object in the <tt>compileReader</tt> method of <tt>org.mozilla.javascript.Context</tt> to compile a script into <tt>org.mozilla.javascript.Script</tt> instances. Under some circumstances it was possible that the scope object would be stored in the compiled form of the script. It made impossible in such cases to reuse of the compiled form to execute the script against different scopes and lead to potential memory leaks.
<p>
</p>Rhino 1.5R5 fixes such misbehavior and <tt>compileReader</tt> and newly introduced <tt>compileString</tt> no longer take the scope argument. For compatibility the old form of <tt>compileReader</tt> is kept as a deprecated method.
All <tt>org.mozilla.javascript.Script</tt> and <tt>org.mozilla.javascript.Function</tt> instances in Rhino now implement the new interface <tt>org.mozilla.javascript.Callable</tt> which together with the new <tt>call</tt> method in <tt>org.mozilla.javascript.Context</tt> gives a simple way to call scripts and functions without explicit calls to <tt>Context.enter()</tt> and <tt>Context.exit()</tt>.
The <tt>Callable</tt> interface allows to set the value of JavaScript <b>this</b> during script execution to arbitrary <tt>org.mozilla.javascript.Scriptable</tt> instance overriding default bahaviour of using the scope object for the value of <b>this</b>.
</p>
<p>Rhino interpreter uses <tt>Callable</tt> to pass references to scripts and functions to <tt>org.mozilla.javascript.SecurityController</tt> directly without wrapping script code into an additional proxy <tt>Script</tt> object. It allows to optimize an implementation of <tt>callWithDomain</tt> method in <tt>org.mozilla.javascript.SecurityController</tt>.
</p>
<p>
For compatibility applications extending the previous version of <tt>SecurityController</tt> are fully supported but the new applications should override <tt>callWithDomain</tt> method, not <tt>execWithDomain</tt>.
Rhino no longer caches generated classes and information about reflected Java classes in static objects. Instead such caches are stored in a top scope object and initialized by default during call to <tt>initStandardObjects</tt> of <tt>org.mozilla.javascript.Context</tt>. This can be overridden with the explicit call to the <tt>associate</tt> method of <tt>org.mozilla.javascript.ClassCache</tt> if cache sharing is desired.
</p>
<p>The cached objects no longer holds references to scope objects so even an application using multiple calls to <tt>Context.initStandardObjects</tt> and single shared <tt>ClassCache</tt> instance would not leak references to runtime library instantiations as it was the case with the previous Rhino for all applications.
The change allows to instantiate multiple Rhino runtime instances which would not interfere with each other and prevents memory leaks through ever growing caches. </p>
<h3>API for compiling scripts into class files</h3>
<p>The new class <tt>org.mozilla.javascript.optimizer.ClassCompiler</tt> provides a simple API to compile JavaScript source into set of Java class files with the given set of compilation options. <ahref="jsc.html">JavaScript Compiler</a> was upgraded to use new API and the old API were deprecated.
<p>The new methods <tt>seal(Object)</tt>, <tt>unseal(Object)</tt> and <tt>isSealed()</tt> in <tt>org.mozilla.javascript.Context</tt> allows to make <tt>Context</tt> instances immune from changes. Rhino embeddings that needs to run potentially untrusted scripts may use the new functionality to proprly implement the sandbox for such scripts without too restrictive <tt>org.mozilla.javascript.ClassShutter</tt> implementation.
</p>
<p>
See <ahref="http://bugzilla.mozilla.org/show_bug.cgi?id=236117">Bugzilla 236117</a>.
In Rhino 1.5R5 the default optimization mode generates only one Java class for script and all its functions while previously the optimizer generated additional class for each function definition in the script. It improves loading time for scripts and decreases memory usage especially for scripts with many function definitions.
</p>
<p>
See <ahref="http://bugzilla.mozilla.org/show_bug.cgi?id=198086">Bugzilla 198086</a>.
The interpreted mode contains significantly less restrictions on size and complexity of the scripts and if the remaining restrictions are not satisfied, Rhino will report an exception instead of generating corrupted internal byte code for interpreting.
which searches <ahref="http://bugzilla.mozilla.org/">bugzilla.mozilla.org</a> for all resolved or verified bugs with the product set to Rhino and the target milestone set to 1.5R5.
