[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with unwanted auto-boxing Java objects in 3.7.1+
From: |
Philip Nienhuis |
Subject: |
Re: Problems with unwanted auto-boxing Java objects in 3.7.1+ |
Date: |
Sat, 26 Jan 2013 22:47:03 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6 |
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>
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.
So far my interpretation is that currently Octave somehow has changed
the way it conveys Java objects to Java. Whether it has always been
wrong (in the OF Java package) and is "correct" (ML compatible?) now, or
the other way round, I can only guess.
Sorry, I forgot the link:
[1]
http://www.openoffice.org/api/docs/common/ref/com/sun/star/frame/XComponentLoader.html
Yep this is the class. The method is 'loadComponentFromURL()'
Debugging the inner workings of the XComponentLoader class is beyond me.
Replacing the third argument to loadComponentFromURL() (currently 0)
with a java.lang.Long didn't make any difference (neither in stable
Octave with OF Java nor in Octave 3.7.1+).
Perhaps a bit prematurely I'll attach the io package function in
question, __UNO_spsh_open__.m, most of all just to provide some insight
in the various Java method calls.
After adding .jars to the javaclasspath by invoking
chk_spreadsheet_support ('', 3, '/full/path/to/libreoffice')
it can be run simply in a stable Octave with Java and io package loaded
using the following commands:
xls.changed = 0;
dbstop __UNO_spsh_open__ 66
xls = __UNO_spsh_open__ (xls, 3, "io-test.xls", 0)
When interrupted at L.66 and dbnext'd until L.72, "whos" gives:
Attr Name Size Bytes Class
==== ==== ==== ===== =====
aLoader 1x1 0 octave_java
a argn 4x13 52 char
f filename 1x48 48 char
flen 1x1 8 double
fname 1x41 41 char
lProp 1x1 0 octave_java
lProps 1x1 0 octave_java
oDesktop 1x1 0 octave_java
tmp 1x12 41 cell
unotmp 1x1 0 octave_java
xComp 1x1 0 octave_java
xContext 1x1 0 octave_java
xMCF 1x1 0 octave_java
xSpdoc 1x1 0 octave_java
f xls 1x1 8 struct
f xlssupport 1x1 8 double
f xwrite 1x1 8 double
Philip