On 01/26/2013 02:42 PM, address@hidden wrote:
> Message: 2
> Date: Sat, 26 Jan 2013 22:47:03 +0100
> From: Philip Nienhuis <address@hidden>
> To: Michael Goffioul <address@hidden>
> Cc: address@hidden
> Subject: Re: Problems with unwanted auto-boxing Java objects in 3.7.1+
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Michael,
>
> Thanks for answering. I've cc'd the maintainers list, OK?
> pls read on:
>
> Michael Goffioul wrote:
>> > On Fri, Jan 25, 2013 at 5:09 PM, Michael Goffioul
>> > <address@hidden <mailto:address@hidden>> wrote:
>> >
>> > On Fri, Jan 25, 2013 at 5:05 PM, Michael Goffioul
>> > <address@hidden <mailto:address@hidden>> wrote:
>> >
>> > On Fri, Jan 25, 2013 at 4:46 PM, PhilipNienhuis
>> > <address@hidden <mailto:address@hidden>> wrote:
>> >
>> > (ref:
>> > https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-December/031429.html)
>> >
>> > While trying to convert the io package spreadsheet scripts
>> > to work with the
>> > new built-in Java interface in 3.7.1+, I hit a bit of a
>> > showstopper with the
>> > UNO interface (LibreOffice/OpenOffice.org) scripts:
>> >
>> > After a bit of fiddling with various LibreOffice Java calls
>> > and objects, the
>> > following call is used in an io package script meant for
>> > opening a
>> > LibreOffice spreadsheet file:
>> >
>> > xComp = aLoader.loadComponentFromURL
>> > ("private:factory/scalc", "_blank", 0,
>> > lProps);
>> >
>> > (where aLoader is a <java_object> of class $Proxy3 in
>> > 3.7.1+, or octave_java
>> > class in 3.6.4-rc1.)
>> >
>> > In 3.6.4-rc1 with the OF Java package, the above call
>> > returns xComp as a
>> > Java object (class octave_java).
>> > However, in 3.7.1+ xComp now gets casted to a plain Octave
>> > (empty) double.
>> > Doubles are not amenable for the next Java method call in line:
>> > xSpdoc = xComp.queryInterface (unotmp)
>> >
>> > Trying to rewrite the offending line into:
>> >
>> > xComp = javaMethod ("loadComponentFromURL", aLoader, ...
>> > "private:factory/scalc", "_blank", 0, lProps)
>> >
>> > doesn't help: still I get an empty double.
>> >
>> > How can the proper class of xComp be retained / obtained?
>> > or, IOW, is there
>> > a way to avoid auto-boxing of Java Objects?
>> >
>> > Thanks,
>> >
>> > Philip
>> >
>> >
>> > What is the java returned type of loadComponentFromURL?
> xComp (the result of aLoader.loadComponentFromURL (<args>) is empty
> double ( 1x1 [] ) in 3.7.1+, but class <octave_java> in stable Octave
> with OF Java package: <Java object: $Proxy4>
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.
Michael.