204576 - 1.5R4 regression: java.lang.String can not be used when argument type is java.lang.CharSequence

Status: VERIFIED FIXED

(Rhino Graveyard :: Core, defect)

Description

[Igor Bukanov]

Given the following script:

var length = Packages.test.length(java.lang.String("test"))
print(length)

where test is Java class 

public class test
{
	public static int length(CharSequence cs)
	{
		return cs.length();
	}
}

Rhino 1.5R3 correctly prints 4 while 1.5R4 and the current tip gives an error;

js: "/home/igor/w/js/x/test.js", line 1: Can't find method test.length(string).

Comment 1

[Igor Bukanov]

Bug 204513 should wait until this regression will be fixed

Comment 2

[Igor Bukanov]

I believe the problem was introduced with the revision 1.26 of NativeJavaMethod
which fixed a problem of selecting overriden methods when used with Cistom wrap
objects:

----------------------------
revision 1.26
date: 2002/04/11 12:56:24;  author: nboyd%atg.com;  state: Exp;  lines: +15 -0
Fix for following problem:

hi Norris,

in our product, which makes heavy use of Rhino, we have many Java Objects
we wrap with ECMAScript wrappers, which extend the ScriptableObject class
and implement the Wrapper interface. Those wrappers automagically wrap the
native Java object with the help of a WrapHandler implementation.

we now ran into a problem :

we have a java class with two overloaded static methods like this :
     public class Test {
         public static String create(File f) {}
         public static String create(Custom c) {}
     }

The Custom class exists as a native Java implementation like
     public class Custom {}

and a accompanying ECMAScript wrapper like
     public class CustomWrapper
        extends ScriptableObject
        implements Wrapper {}

in our ECMAScripts we make the wrapper class known as a host object along
the lines of
     defineClass("CustomWrapper");
and can then use the object as a normal ECMAScript host object. no big deal
and working great.

but : the code
     var s = Test.creat( new Custom( "xyz") );
fails with the information, that the methods are ambiguous, which of course
they are not.

Looking at the code of NativeJavaMethod.findFunction() and the helpers in
NativeJavaObject it seems, that the fact of the Custom host object being a
Wrapper is not taken into account. in an easy fix of
NativeJavaMethod.findFunction(), i simply replace all arguments, which are
Wrapper imlpementation by the wrapped object. this solves my problem, but
of course i'm not sure on side effects.

i attach the testcase as well as the fixed NativeJavaMethod class in the
jar file. to run the test with and without the fix, extract the jar and do
     ant test

please let me know, what you think of this.

regards and thanks, f.

Felix Meschberger
----------------------------

The problem is that the fix unconditionally unwraps wrapped java.lang.String
which means that they are treated as JS primitive strings and that are not
supported with java.lang.CharSequence.

Comment 3

[Igor Bukanov]

Attachment: Test case for custom wrap problem as a patch file

Any fix should not only address the problem itself but also keeps working
custom wrapping, so here is a test case to check that as well. To run it,
compile 204576/CustomWrapFactory.java and then run 204576/wrap_test.js with the
Rhino shell. It should print 
size Vector: 0
size Hashtable: 0

Comment 4

[Igor Bukanov]

Attachment: Fix: proper handling of custom wrappers

The fix idea is to make sure that all code like (obj instanceof
NativeJavaObject) should be replaced by (obj instanceof Wrapper) since the idea
of Wrapper interface introduction is to use it instead of NativeJavaObject in
the LiveConnect code. It turned out the only such place left is
NativeJavaObject.getJSTypeCode which the patch replaces. Then the patch undo
the initial fix.

Comment 5

[Igor Bukanov]

I committed the fix.

Comment 6

[Igor Bukanov]

I put the fix to Rhino150R4_BRANCH as well. It a pity that the problem was found
after 1.5R4.1 but if someone wants a Rhino with just that version fixed, the
branch can be used.

Comment 7

[Phil Schwartau]

Verified FIXED.

We compare Rhino1_5R3 vs. Rhino1_5R5pre before and after the fix:

Rhino1_5R3
[ ] java -classpath ".;D:/JS_TRUNK/mozilla/js/rhino/build/rhino1_5R3/js.jar" 
         org.mozilla.javascript.tools.shell.Main
Rhino 1.5 release 3 2002 01 24
js> var length = Packages.test.length(java.lang.String("test"))
js> length
4


Rhino1_5R5pre BEFORE
[ ] java -classpath ".;D:/JS_TRUNK/mozilla/js/rhino/build/rhino1_5R5pre/js.jar" 
         org.mozilla.javascript.tools.shell.Main
Rhino 1.5 release 5 0000 00 00
js> var length = Packages.test.length(java.lang.String("test"))
js: "<stdin>", line 1: Can't find method test.length(string).


Rhino1_5R5pre AFTER
[ ] java -classpath ".;D:/JS_TRUNK/mozilla/js/rhino/build/rhino1_5R5pre/js.jar"  
          org.mozilla.javascript.tools.shell.Main
Rhino 1.5 release 5 0000 00 00
js> var length = Packages.test.length(java.lang.String("test"))
js> length
4

Comment 8

[Igor Bukanov]

Targeting as resolved against 1.5R5