The Java I/F in core is still not 100% complete. This is
perhaps the
biggest problem. Major changes have been made to the box
routine
(Java->Octave) to make it work for more different return
arguments and to
make it compatible with Matlab. Support for arrays in box()
is still not
really there. The unbox routine (Octave->Java) is based on
an incorrect
premise. It uses the Octave data type to guess the data type
for the Java
routine. It should instead use the Java method signature to
determine what
input types are required and then work out how to coerce the
Octave data
type into the correct Java type. Michael pointed out a
routine which can
get the Java method signature so this problem can be overcome,
but it
hasn't been coded yet.
That's not exactly what I said. The code to look for the
right method with suitable argument casting *is* already
implemented in org.octave.ClassHelper.java (in the methods
getMethod, isCallableFrom and castArgument). The way it works
is that basic/naive octave/java type mapping is performed in
C++, then another mapping is done in java, based on the actual
method signatures and the possibility to cast the arguments to
the expected type. The reason it is done that way is because
it was way much easier to deal with java introspection in Java
itself, than in JNI.
For instance, if you call: javaInvoke (obj, "myfun", 1)
in octave, the argument "1" will first be converted to a
java "double" and passed down to the Java world. In Java, the
ClassHelper will first look for a method with signature
"myfun(double)". If it doesn't find one, it searches all
methods with a matching number arguments and signature
"myfun(T)" where "double" can be casted to "T". If it finds
one, it'll execute it with casting the argument "1" to the
java type "T".
You may think it's an incorrect premise, but I find it
quite reasonable.