Re: Java boxing

[Philip Nienhuis]

Following up on an old post .... (see below)


Rik-4 wrote
> On 01/26/2013 02:42 PM, 

> octave-maintainers-request@

>  wrote:
>> Message: 2
>> Date: Sat, 26 Jan 2013 22:47:03 +0100
>> From: Philip Nienhuis <

> pr.nienhuis@

> >
>> To: Michael Goffioul <

> michael.goffioul@

> >
>> Cc: 

> octave-maintainers@

>> Subject: Re: Problems with unwanted auto-boxing Java objects in 3.7.1+
>> Message-ID: <

> 51044ED7.7070303@

>>
>> 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
>>> > &lt;

> michael.goffioul@

>  &lt;mailto:

> michael.goffioul@

> &gt;> wrote:
>>> >
>>> >     On Fri, Jan 25, 2013 at 5:05 PM, Michael Goffioul
>>> >     &lt;

> michael.goffioul@

>  &lt;mailto:

> michael.goffioul@

> &gt;> wrote:
>>> >
>>> >         On Fri, Jan 25, 2013 at 4:46 PM, PhilipNienhuis
>>> >         &lt;

> pr.nienhuis@

>  &lt;mailto:

> pr.nienhuis@

> &gt;> 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).

The issue turned out to be that Octave "logical" class isn't automatically
"casted" (?) into a Java Boolean class anymore, as it was in the OF Java
package.
Somewhere higher up in the relevant code I had a statement:

lProp = javaObject ("com.sun.star.beans.PropertyValue", "Hidden", 0, true,
[]);

which had to be replaced by:

jtrue = javaObject ("java.lang.Boolean", "true");
lProp = javaObject ("com.sun.star.beans.PropertyValue", "Hidden", 0, jtrue,
[]);

(Same had to be done in other parts of the code.)
After that I could use Open/LibreOffice as before from Octave.

I can't judge whether this is a bug or just new behavior. If you think it's
a bug I'll file a bug report.

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Re-Java-boxing-tp4649148p4650673.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.