octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Java Bool type


From: Rik
Subject: Re: Java Bool type
Date: Mon, 11 Mar 2013 16:40:31 -0700

On 03/11/2013 02:35 PM, Philip Nienhuis wrote:
> (maintainers ML added)
>
> Rik wrote:
>> On 03/11/2013 12:46 PM, Philip Nienhuis wrote:
>>> Rik wrote:
>>>> On 03/10/2013 02:00 PM, address@hidden wrote:
>>>>> The issue turned out to be that Octave "logical" class isn't
>>>>> automatically
>>>>> "casted" (?) into a Java Boolean class anymore, as it was in the OF Java
>>>>> package.
>>>>> Somewhere higher up in the relevant code I had a statement:
>>>>>
>>>>> lProp = javaObject ("com.sun.star.beans.PropertyValue", "Hidden", 0,
>>>>> true,
>>>>> []);
>>>>>
>>>>> which had to be replaced by:
>>>>>
>>>>> jtrue = javaObject ("java.lang.Boolean", "true");
>>>>> lProp = javaObject ("com.sun.star.beans.PropertyValue", "Hidden", 0,
>>>>> jtrue,
>>>>> []);
>>>>>
>>>>> (Same had to be done in other parts of the code.)
>>>>> After that I could use Open/LibreOffice as before from Octave.
>>>>>
>>>>> I can't judge whether this is a bug or just new behavior. If you think
>>>>> it's
>>>>> a bug I'll file a bug report.
>>>> 3/10/13
>>>>
>>>> Philip,
>>>>
>>>> I would report this as a bug so we can track it.  For compatibility with
>>>> Matlab
>>>> (http://www.mathworks.com/help/matlab/matlab_external/passing-data-to-a-java-method.html),
>>>>
>>>>
>>>> and because it is the sensible thing to do, logical values should be
>>>> converted to native boolean Java types where possible.  The code for
>>>> doing
>>>> this is still in the unbox routine, but it looks like it may not be
>>>> activated because it is too low down in the if/else if tree.  Please try
>>>> the attached patch (patch -p1<   patch.java_bool) and see whether it
>>>> eliminates the need to create a jtrue object.
>>>
>>> Thanks Rik,
>>>
>>> I'll try later this week (no time now), Tue or Wed.
>>>
>>> I could also first try some std::cout<<  debug statements to see if the
>>> code is reached at all.
>> 3/11/12
>>
>> Philip,
>>
>> I did something similar and used gdb to step through the code to verify it
>> was called.
>>
>> This used the Boolean code:
>> x = javaObject ('java.lang.Boolean', true);
>>
>> This used the Double code
>> x = javaObject ('java.lang.Boolean', 1);
>
> Was x in the 2nd example a Java boolean object or a Java double object?
> If double I'm not sure what to do.
> Most users would probably expect to be returned a Java boolean object
> though.
>
> See e.g., http://docs.oracle.com/javase/6/docs/api/, click "java.lang" in
> top left column, then "Boolean" in lower left column under Classes, for
> what java.lang.Boolean formally expects as input.
>
3/11/13

Philip,

'x' is a variable within Octave.  It is overwritten by whatever is created
on the right-hand side.  You can use 'y' as the variable name for the
second instance if you want to verify that both x and y are objects of type
java.lang.Boolean with value 'true'.

This was just a convenient test for me to make sure the code was being
executed.  The actual behavior to match is in the table "Conversion of
MATLAB Types to Java Types" found here
http://www.mathworks.com/help/matlab/matlab_external/passing-data-to-a-java-method.html.
 
In the second case, class double is being cast to boolean as the least
closest match, but still a match for the constructor function signature
which expects a Boolean input value.

The new code is definitely getting exercised. 

x = javaObject ('java.lang.Double', 1)   # works
y = javaObject ('java.lang.Double', true) # works with old code / fails
with new code

--Rik



The table "Conversion of MATLAB Types to Java Types" determines what we are
trying t
> Philip
>
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]