[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Java boxing
From: |
Philip Nienhuis |
Subject: |
Re: Java boxing |
Date: |
Sun, 10 Mar 2013 13:35:41 -0700 (PDT) |
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
>>> > <
> michael.goffioul@
> <mailto:
> michael.goffioul@
> >> wrote:
>>> >
>>> > On Fri, Jan 25, 2013 at 5:05 PM, Michael Goffioul
>>> > <
> michael.goffioul@
> <mailto:
> michael.goffioul@
> >> wrote:
>>> >
>>> > On Fri, Jan 25, 2013 at 4:46 PM, PhilipNienhuis
>>> > <
> pr.nienhuis@
> <mailto:
> pr.nienhuis@
> >> 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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Java boxing,
Philip Nienhuis <=