|Harald Kuhr||Feb 9, 2010 11:58 am|
|Duncan McGregor||Feb 9, 2010 12:04 pm|
|Harald Kuhr||Feb 9, 2010 12:27 pm|
|Harald Kuhr||Feb 9, 2010 12:37 pm||.java|
|Duncan McGregor||Feb 10, 2010 12:37 am|
|Harald Kuhr||Feb 10, 2010 2:39 am||.java|
|Harald Kuhr||Feb 17, 2010 7:25 am|
|Duncan McGregor||Feb 18, 2010 1:56 am|
|Andrew Thompson||Feb 18, 2010 6:52 pm|
|Harald Kuhr||Feb 19, 2010 6:49 am|
|Harald Kuhr||Feb 19, 2010 7:23 am|
|Harald Kuhr||Feb 19, 2010 10:37 am|
|Harald Kuhr||Feb 19, 2010 12:13 pm|
|Duncan McGregor||Feb 19, 2010 2:04 pm|
|Harald Kuhr||Feb 19, 2010 3:06 pm|
|Andrew Thompson||Feb 20, 2010 8:02 am|
|Harald Kuhr||Feb 20, 2010 1:12 pm|
|Andrew Thompson||Feb 20, 2010 5:22 pm|
|Duncan McGregor||Feb 21, 2010 2:55 am|
|Harald Kuhr||Feb 21, 2010 8:14 am|
|Duncan McGregor||Feb 21, 2010 8:40 am|
|Duncan McGregor||Feb 21, 2010 9:01 am|
|Subject:||Re: BOOL mapping issues|
|From:||Duncan McGregor (dun...@oneeyedmen.com)|
|Date:||Feb 18, 2010 1:56:27 am|
I've played with it a bit, and am as flummoxed as you. It seems that calling to
setHidden(bool) with true of false will make the return from isHidden() false.
Rococoa does no marshalling in this area - it assumes that you had the signature
right, and lets JNA do the heavy lifting. In fact by the time it gets to a
method invocation, the arguments are all passed to the vargs objc_msgSend
functions, so it's all typeless by then. But in any case, JNA maps Java bool and
Java int to the same type in C.
The other thing that we pass to objc_msgSend is the selector. This is basically
a pointer to the interned method name as a string. That means (I think ;-) that
ObjC classes cannot have a setHidden:(bool) and setHidden:(int) as they will
both have the same selector.
You can see this runtime behaviour if you add
public void setHidden(Object hidden)
to NSView, and then call it
view.setHidden((Object) Integer.valueOf(1)); assertTrue("Should be hidden", view.isHidden()); // ok
view.setHidden((Object) Integer.valueOf(0)); assertFalse("Should be hidden", view.isHidden()); // ok
view.setHidden((Object) Boolean.TRUE); assertTrue("Should be hidden", view.isHidden()); // fails
The code paths in Rococoa are identical for these invocations!
FWIW I have tried this with the current SVN head at Google Code, and the results
are the same. Maybe David and Olivier could try to reproduce with their
auto-generated mappings and report back?
On 17 Feb 2010, at 15:25, Harald Kuhr wrote:
Have anyone had the time to look into this?
If not, does anyone have pointers to where I should start digging?
-- Harald K
On 10. feb. 2010, at 11.40, Harald Kuhr wrote:
On 10. feb. 2010, at 09.38, Duncan McGregor wrote:
If it's only reproducible for NSView, then our marshalling must be working fine
Well.. NSView is a valid class too, and I think I have proven that there's
something wrong with the mapping there. Even though it seems to work fine most
of the time. ;-)
Unfortunately I don't know why though... My initial guess would be that there
could be more setHidden methods in NSView, and that confuses Rococoa or JNA to
select the wrong one. That's at least a bug I've seen before in reflective Java
code. But I really don't know where to start looking.
Should I talk to someone on the JNA list maybe?
What if you rearrange the order of the invocations?
Does not matter. But I've created a better test case, that tests all the
transitions possible (false/false, true/false, false/true and true/true), and
the two latter will fail consistently. This means that the invocation
setHidden(true) will set the hidden state to NO...
-- Harald K