4
votes

I have some MATLAB code and some Java code that need to talk with each other. I was getting a NoSuchMethodError. When I pass a MATLAB double array to a Java method that accepts double[] argument.

So I write a simple "hello world" to get the class of an object passed to the method

public void printArray(Object array) {

        System.out.println(array.getClass());
        System.out.println(array.getClass().getPackage());
    }

Calling this method from MATLAB, I get this interesting output:

>> a.printArray(2)
class java.lang.Double
package java.lang
>> a.printArray('hello')
class java.lang.String
package java.lang
>> a.printArray(true)
class java.lang.Boolean
package java.lang
>> a.printArray([2 3 4])
class [D
null
>> a.printArray([true false])
class [Z
null

Can someone explain whats happening. I have MATLAB R14 and the Java class is compiled with 1.3 compatibility.

5
Seems like expected behavior... the arrays are of primitive booleans and doubles. Could you perhaps describe the code that gives you the NoSuchMethodError exception?Zach Scrivena

5 Answers

2
votes

I think the original problem has been updated by the OP, so I'll take the chance to summarize our findings so far:

  • We have established that the sample code in the original question produces the expected behavior. MATLAB passes data as primitives to Java, and Java performs the appropriate autoboxing to Objects. As pointed out in Matthew Simoneau's reply, MATLAB explains how it matches its data types to Java data types in the "Passing Data to a Java Method" section of its documentation. The surprising thing is that a single MATLAB data type may match different Java data types, e.g. logical matches boolean, byte, short, int, long, float, and double, in that order of precedence.

  • The NoSuchMethodError that the OP initially encountered was caused by the use of a wrong method. This is no longer a problem. Using double[] as the method argument works.

  • The "strange" class names ([D and [Z) are actually notations used by Java to describe arrays of primitive types. The API explains the usage in Class.getName().

Case closed =)

2
votes

Looks simple to me: Matlab passes numbers to Java as Double instances, strings as String instances, booleans as Boolean instances, and arrays as Java arrays. So try changing your method signature from method(double[] blah) to method(Double[] blah).

2
votes

MATLAB has a set of heuristics to convert MATLAB data types to the type required by the Java method being called. The full details are described in Passing Data to a Java Method in the MATLAB documentation.

The method's signature, void printArray(Object array), doesn't give MATLAB much information about what Java really wants. This is why you're seeing a variety of types, depending on how you call it.

With respect to your original question, I'm not sure why this wouldn't be working for you. Give a close look at Passing Built-In Types.

It gives the sample MATLAB code

poly = java.awt.Polygon([14 42 98 124], [55 12 -2 62], 4);

where the corresponding Java method has the signature

public Polygon(int xpoints[], int ypoints[], int npoints)

This is a little different than your question because it involves arrays of ints rather than arrays of doubles, but should work identically.

0
votes

Apperantly java accepts the array quite fine. Its the Arrays.toString() method that fails to work on that input. I used double[] in the method signature and printed the array in a loop, and it worked. However it is still an open question as to why the strange class names apear.

0
votes

As others have said, it's the expected behaviour. Java arrays just don't have a very useful string representation. If you want to get a more useful string representation of your arrays, you could wrap them in a List, like:

Arrays.asList(new Double[] { 1.1, 2.2, 3.3 })