Closed Bug 456546 Opened 16 years ago Closed 16 years ago

Java method lookup fails for methods with Scriptable argument if argument is a subclass

Categories

(Rhino Graveyard :: Core, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: hannesw, Unassigned)

Details

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: 

The method lookup in NativeJavaObject fails if the target method takes a Scriptable argument and the actual argument is a subclass of the formal parameter.

js> org.mozilla.javascript.Context.currentContext.initStandardObjects({})
js: "<stdin>", line 3: Can't find method org.mozilla.javascript.Context.initStandardObjects(object).
	at <stdin>:3

Reproducible: Always
Attached patch fixSplinter Review
Use Class.isInstance() instead of ==
Committing the patch.

Checking in src/org/mozilla/javascript/NativeJavaObject.java;
/cvsroot/mozilla/js/rhino/src/org/mozilla/javascript/NativeJavaObject.java,v  <--  NativeJavaObject.java
new revision: 1.86; previous revision: 1.85
done
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
The previous patch causes passing a Scriptable arg to a java.lang.Object parameter to get a conversion weight 1:

js> var sdf = new java.text.SimpleDateFormat();
js> sdf.format(new Date());
js: "<stdin>", line 3: The choice of Java constructor format matching
JavaScript argument types (object) is ambiguous; candidate
constructors are:
    class java.lang.String format(java.lang.Object)
    class java.lang.String format(java.util.Date) 

This patch additionally checks if the formal parameter is actually Scriptable or an class implementing Scriptable.
I committed the second patch to both Rhino1_7R2_BRANCH and HEAD.
The second patch was too broad. It prevented objects implementing Scriptable to be used for parameters of any other interface or superclass they may implement/extend. 

For example, org.mozilla.javascript.ScriptableObject now implements java.util.Map, but calling new java.util.HashMap({foo: "bar"}) fails because of this.

With the new patch, all formal parameter interfaces/classes that are directly implemented by the Scriptable instance produce a conversion weight of 1, except java.lang.Object, which produces a conversion weight of 2 (which is I think the intended behaviour).
I committed the new patch.

Checking in src/org/mozilla/javascript/NativeJavaObject.java;
/cvsroot/mozilla/js/rhino/src/org/mozilla/javascript/NativeJavaObject.java,v  <--  NativeJavaObject.java
new revision: 1.89; previous revision: 1.88
done
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: