X

Sundararajan's Weblog

  • Java
    January 12, 2007

Overloading and Scripting

Guest Author

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.

Join the discussion

Comments ( 2 )
  • Michael Nascimento Santos Friday, January 12, 2007
    Hi,

    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.
  • A. Sundararajan Friday, January 12, 2007
    I got the following result with Rhino 1.6R5 (the latest release as of now)
    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?
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.