Re: Auto-boxing Java numerical values

[Philip Nienhuis]

Philip Nienhuis wrote
> 
> Rik-4 wrote
>> On 12/20/2012 02:28 PM, 

>> octave-maintainers-request@

>>  wrote:
>>> Message: 1
>>> Date: Thu, 20 Dec 2012 13:38:18 -0800 (PST)
>>> From: Philip Nienhuis <

>> address@hidden

>> >
>>> To: 

>> octave-maintainers@

>>> Subject: Auto-boxing Java numerical values (cs 15820:00172e5c2302)
>>> Message-ID: <

>> address@hidden

>>>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Rik,
>>>
>>> I saw you've extended 'autoboxing' of Java doubles into Octave doubles
>>> to
>>> Java short/long/float etc.
>>> Isn't there a risk that this will definitely break code unavoidably
>>> depending on the old behavior?
>>>
>>> Example:
>>> In the io package there's code invoking LibreOffice (behind the scenes)
>>> through a UNO-Java bridge. Somewhere in that code LibreOffice (i.e., a
>>> UNO
>>> Java method) expects a Java short value or object. If Octave casts that
>>> java.lang.Short object into a double, how can that short value be
>>> conveyed
>>> to Java? AFAICS there's no way to typecast Octave values into Java class
>>> types. Or can we now do:
>>>
>>>   
>> <SomeOctaveDouble>
>> .shortValue()
>>>
>>> ? (i.e., applying Java methods to amenable Octave classes)
>>>
>>> AFAICS Matlab simply doesn't do any, or very limited, 'autoboxing'.
>> The documentation,
>> http://www.mathworks.com/help/matlab/matlab_external/handling-data-returned-from-a-java-method.html,
>> has a table showing how each Java return type is converted to a Matlab
>> type.  For all numeric scalar values Matlab chooses double which is what
>> the changeset in question does.
>> 
>> Again, this is worth verifying in case actual behavior does not match the
>> documentation.  What does the following return?
>> 
>> x = javaObject ('java.lang.Double', 4.2);
>> y = x.shortValue;
>> class (y)
> I'll try that later. If the ML docs are right this would return a double.
>> I think the real issue is with the unbox routine.  When you call a Java
>> method Octave invokes unbox() to convert its native type to a
>> corresponding
>> Java type.  In the case you mention, Octave should look at the method
>> signature and see that the UNO method wants a short and do that
>> conversion.  Unfortunately, the unbox code does nothing of the sort and
>> is
>> looking at the Octave class to try and guess what the appropriate Java
>> class would be.  This is just one of the issues needing attention with
>> Java.
> So boxing works but unboxing doesn't? I'd rather have these
> implementations symmetrical until unboxing works for all boxing
> operations. Or perhaps I didn't understand properly?
> 
> I'll try the io code as soon as I have a recent tip built (maybe maybe
> tonight). That'll tell what works and what not.

(Luckily just two files changed since last build so fast results) tip:
15823:bc7a130bbdfb tip

Rik

I wonder if I correctly understood how you intended 'boxing' to work in
Octave.
With the latest tip (see above):

octave:1> x = javaObject ('java.lang.Short', 23)
x =

<Java object: java.lang.Short>

octave:2> x + 1
error: binary operator '+' not implemented for 'octave-java' by 'scalar'
operation 

Wasn't it intended that x would be transformed right away to (Octave)
double? Or is it only valid for Java doubles?

(Elsewhere quite some code in the io package and Octave itself got broken
with these boxing changes, e.g. javamem.m. I'll fix the latter soon, just a
matter of removing three .doubleValue method calls)

Philip




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