380032 - LiveConnect reports method selection ambiguity in clearly unambiguous cases when passing native Java arrays

Status: RESOLVED DUPLICATE of bug 376792

(Rhino Graveyard :: Core, defect)

Description

[Thomas Chust]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1
Build Identifier: Rhino 1.6 release 5 2006 11 18

Let K be a Java class that provides a public methods m with at least two overloads with the same number of arguments and one argument being specialized once as any array type and once as int. For example:

  public class K {
    public static void m(int i) {
      System.out.println("K.m(int) called");
    }
    public static void m(byte[] bs) {
      System.out.println("K.m(byte[]) called");
    }
  }

Now consider the following examples of using this class through Rhino's live connect:

  $ java org.mozilla.javascript.tools.shell.Main
  Rhino 1.6 release 5 2006 11 18
  js> var K = Packages.K
  js> K.m(42)
  K.m(int) called
  js> K.m([ 1, 2, 3 ])
  K.m(byte[]) called
  js> K.m(java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, 4))
  js: "<stdin>", line 5: The choice of Java constructor m matching JavaScript argument types ([B) is ambiguous; candidate constructors are: 
      void m(int)
      void m(byte[])
  js: "<stdin>", line 5: org.mozilla.javascript.EvaluatorException: The choice of Java constructor m matching JavaScript argument types ([B) is ambiguous; candidate constructors are: 
      void m(int)
      void m(byte[]) (<stdin>#5)

The third call fails because Rhino is not sure whether to pass a native Java byte[] as a native Java byte[] or an int?!?

If I understand it correctly, this behaviour contradicts the LiveConnect specification at http://www.mozilla.org/js/liveconnect/lc3_method_overloading.html which says that a wrapped native Java array is never converted to any numeric type by live connect.

Moreover, suppose our example class K had another public method n defined as follows:

    public static void n(int i) {
      System.out.println("K.n(int) called");
    }

Then the LiveConnect call to this method using a byte array argument fails as well:

  js> K.n(java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, 4))
  js: "<stdin>", line 6: Cannot convert [B@1ef443 to java.lang.Integer
  js: "<stdin>", line 6: org.mozilla.javascript.EvaluatorException: Cannot convert [B@1ef443 to java.lang.Integer (<stdin>#6)

To me this looks as if Rhino tried to convert the array first to a string before checking LiveConnect argument types and then the string to a number before actually performing the call to Java.


Reproducible: Always

Steps to Reproduce:
1. Create a file K.java with the following content:

  public class K {
    public static void m(int i) {
      System.out.println("K.m(int) called");
    }
    public static void m(byte[] bs) {
      System.out.println("K.m(byte[]) called");
    }
    public static void n(int i) {
      System.out.println("K.n(int) called");
    }
  }

2. Compile the Java source created in step 1

3. Launch the Rhino JavaScript shell

4. Try to call a method in the class you just created using

  Packages.K.m(java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, 4))

Actual Results:  
The call fails with an exception in LiveConnect code


Expected Results:  
The call should be performed normally

Although this bug is especially annoying when trying to write byte arrays onto Java output streams, it is possible to circumvent it by explicitly specifying the method signature to call -- in the above example Packages.K["m(byte[])"](java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, 4)) would do the job.

Comment 1

[Norris Boyd]

I think this would be resolved by the fix to 376792. Marking duplicate now; should recheck this bug is fixed when 376792 is fixed.