Re: Auto-boxing Java numerical values

[Philip Nienhuis]

Philip Nienhuis wrote
> 
> 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

ML r2013a (prerelease) gives:

>> x = javaObject ('java.lang.Short', 23)
 
x =
 
23
 
>> x + 1
Undefined function 'plus' for input arguments of type 'java.lang.Short'.
 
>> x.doubleValue + 1

ans =

    24

>> x = javaObject ('java.lang.Double', 4.2);
>> y = x.shortValue;
>> class (y) 

ans =

double

>> 

so Octave seems "compatible".

Philip



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