Re: Auto-boxing Java numerical values

[Philip Nienhuis]

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.

Philip




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