Friday January 12, 2007
JDK 6 includes Mozilla Rhino based implementation of javax.script API for JavaScript. There are javax.script engines for other scripting languages are available at scripting.dev.java.net. The scripting languages for the Java platform offer someway of accessing Java classes from scripts. Most of these scripting languages being dynamically typed, user does not supply type information -- which makes it difficult to interact with Java classes. For example, method overload resolution - which is done by javac - has to be done using dynamic type of the arguments in scripting languages. Scripting languages choose their own policy to pick the "correct" overload variant when a script calls a (overloaded) Java method. Yesterday, Michael Nascimento Santo reported a bug against JavaScript engine in JDK 6. I believe this is not a bug.
First, this is not an issue with javax.script implementation on top of Rhino. This can be seen by running Rhino's shell [which comes with Mozilla Rhino download] - avoiding the jsr-223 API cover. Using Rhino 1.6R2 [which is the version bundled with JDK 6], I got the following result:
D:\rhino1_6R2>java -cp js.jar;. org.mozilla.javascript.tools.shell.Main
Rhino 1.6 release 2 2005 09 19
js> p = new Packages.FunctionsClass()
FunctionsClass@f81843
js> p.equals("x", "x")
js: "<stdin>", line 3: Can't find method java.lang.Object.equals(string,string).
js: "<stdin>", line 3: org.mozilla.javascript.EvaluatorException: Can't find met
hod java.lang.Object.equals(string,string). (<stdin>#3)
js> Packages.FunctionsClass.equals('x', 'x')
true
Clearly, Rhino itself does not find that particular static method when calling through an instance. I believe this is a design choice by Rhino. Please refer to bullet 2 of section 3.1 of http://www.mozilla.org/js/liveconnect/lc3_method_overloading.html.
All scripting languages for the Java platform have to choose some policy for method overload resolution. If the invokedynamic bytecode has to handle overloading at runtime, you can imagine how problematic that would be! JVM has to make the overload resolution at runtime using the dynamic types of arguments (consider boxing/unboxing too)! Apart from possible performance issues, the policy chosen for the overload resolution may "hurt" some scripting language. I think most likely the invokedynamic bytecode would require method signature -- thereby leaving the overload resolution to the scripting language runtime.
This is a bug. It works with Rhino 1.5-R3 and with Rhino 1.6R5. So, if they fixed it again in Rhino 1.6 (can't find the exact release now), I guess they agree with me.
Posted by Michael Nascimento Santos on January 12, 2007 at 06:23 PM IST #
D:\rhino1_6R5>java -cp js.jar;. org.mozilla.javascript.tools.shell.Main Rhino 1.6 release 5 2006 11 18 js> p = new Packages.FunctionsClass() FunctionsClass@dd5b js> p.equals('x', 'x') js: "<stdin>", line 3: Can't find method java.lang.Object.equals(string,string). js: "<stdin>", line 3: org.mozilla.javascript.EvaluatorException: Can't find method java.lang.Object.equals(string,string). (<stdin>#3) js> quit()Am I missing something?Posted by A. Sundararajan on January 12, 2007 at 07:21 PM IST #