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:
Rhino 1.6 release 2 2005 09 19
js> p = new Packages.FunctionsClass()
js> p.equals("x", "x")
js: "<stdin>", line 3: Can't find method java.lang.Object.equals(string,string).
hod java.lang.Object.equals(string,string). (<stdin>#3)
js> Packages.FunctionsClass.equals('x', 'x')
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
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.