Re: Java boxing

[Philip Nienhuis]

Rik wrote:
> On 01/26/2013 02:42 PM, address@hidden wrote:
> > Message: 2
> > Date: Sat, 26 Jan 2013 22:47:03 +0100
<snip>
> > > >              How can the proper class of xComp be retained / obtained?
> > > >              or, IOW, is there
> > > >              a way to avoid auto-boxing of Java Objects?

> 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.

(see Michael's follow-up post on this. Most if not all of that latter 
procedure has been inherited from the OF Java package and just works)

What you implicitly suggest is that I'd better suspend porting the io 
package to Octave 3.7.1+.
Well, the current state is that all .xls interfaces (POI, JXL, OXS) work 
(they pass the tests in io_xls_testscript.m in the io package), and I 
expect the .ods interfaces (OTK, JOD) to work w/o much amendments. I'm 
not pessimistic.

Only UNO is a PITA. But admittedly, LO/OOo's UNO-Java bridge invokes 
such highly abstracted data types and methods that apparently even in 
pure Java it is hard to get it implemented; the many posts in 
www.oooforum.org on even trivial issues bear witness to that.

> 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.

Yes,
http://www.mathworks.nl/help/matlab/matlab_external/handling-data-returned-from-a-java-method.html

(We've had a disussion on this subject earlier on.)

Very probably I don't understand the Java internals very well; I can 
only invoke ready-baked Java classes. But my experience with the io 
package may help to get some insight in user expectation and -desires.

The ML way (auto-boxing about any numerical return type to double) 
simply can be a bit too much dumbed down. Preserving the Java object 
might be desirable in some cases, e.g. subsequent manipulation of the 
Java object in other Octave functions/scripts that invoke Java methods.
Perhaps we might need a user setting to switch that boxing on or off on 
the fly.

1.5 years ago, while writing the UNO-Java (Libre/OpenOffice) spreadsheet 
interface for Octave, I did large parts simultaneously in Matlab at 
work. At some point I had to give up on Matlab, and IIRC it was 
precisely because of this issue.
I'm a bit afraid that full ML compatibility might have the effect of 
decreased versatility compared to the OF Java package.

An alternative would be to write dedicated class libs (.jar files) as an 
intermediate layer between Octave and dedicated Java class libs for each 
application. I'm afraid that is beyond me. In addition such a 
requirement might affect the current ability to invoke readily baked 
Java class libs directly from within Octave, which IMO at present is a 
great asset.

Philip