Re: Java boxing

[Rik]

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.

In your example, a scalar numeric value of any type (Double, Float, Short,
Int, Byte) is always returned as a scalar double value which is Matlab
behavior.  I think that something probably went wrong earlier and this
piece of code is returning a single double value as an error code.
>
> For how it looks in Windows (in Octave3.6.2MSVC2010) see below.
>
> All Java objects created by the Libre/Open-Office UNO Java classes are 
> of the <octave_java> class, or $Proxy<some_number> (an OpenOffice.org 
> idiosyncray) for stable Octave versions with OF Java package.
>
>> >     If this [1] is the function we're talking about, I suspect it's
>> >     actually returning NULL and you get an empty matrix on the octave
>> >     side. This would then indicate that the method fail. Maybe the
>> >     problem is due to incorrectly casting the method arguments?
> You may be right here, but it would be 'casting' from Octave to Java.
>
> All I can see is that the method in question fails (and indeed, probably 
> returns NULL) in Octave 3.7.1+ while it does work OK in 3.6.4.-rc1.
> So, something did change when the Java package was absorbed in core Octave.
>
> I did some more investigating; it turns out that creating a new file 
> fails, but opening an existing spreadsheet succeeds, however the latter 
> with a visible OOo/LO spreadsheet window (should be hidden).
> I suspect the latter happens because the Java 1x1 array lProps (the 4th 
> argument to the failing method) gets mangled somehow. But that doesn't 
> explain why creating a new file fails completely, as both calls to 
> aLoader.loadComponentFromURL (i.e., creating/opening a file) only differ 
> in the first filename argument.
Debugging a part of the problem may help with the whole.  Some
documentation on the PropertyValue object for OpenOffice 3.4 is here
(http://www.openoffice.org/api/docs/common/ref/com/sun/star/beans/PropertyValue.html).
 
It seems to suggest that the Handle should be -1, not 0, if the Handle is
not used.  That would be something to try.

Also, here is a report about someone else dealing with trying to pass the
"Hidden" property
(http://forum.openoffice.org/en/forum/viewtopic.php?f=44&t=41379).  They
ended up not passing a Java Boolean, but rather an object of uno.Any (True).

--Rik