6 messages in net.java.dev.jna.usersRe: [jna-users] Pointer to structure ...
FromSent OnAttachments
Jean-Baptiste BugeaudMay 16, 2007 7:08 am 
Timothy WallMay 17, 2007 10:40 am 
Timothy WallMay 17, 2007 11:20 am 
Jean-Baptiste BugeaudMay 18, 2007 5:55 am 
Timothy WallMay 18, 2007 6:51 am 
Jean-Baptiste BugeaudMay 18, 2007 1:11 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [jna-users] Pointer to structure arrays ?Actions...
From:Jean-Baptiste Bugeaud (buge@gmail.com)
Date:May 18, 2007 1:11:09 pm
List:net.java.dev.jna.users

Hello Tim,

2007/5/18, Timothy Wall <twal@dev.java.net>:

I've filed an issue for this.

https://jna.dev.java.net/issues/show_bug.cgi?id=16

First thank you for the long answer you have given, the time you are dedicating to this nice project and the issue submission you have made. Just cool :o)

On May 18, 2007, at 8:56 AM, Jean-Baptiste Bugeaud wrote:

Hello Tim,

The example you have given (overriding of constructor) is not working with the existing toArray either ! Simply because, the allocateMemory is overriding the size field, which will make an ArrayIndexOutOfBoundsException on the second iteration inside the structure.toArray.

I hope next versions will support array of Structures. But this may lead to limitation of current memory mapping (to be verified).

You are correct, you'd have to do additional overriding of size(), which is probably more work than patching in the correct behavior in the first place.

FYI, I've tried to override the toArray with calculateSize() instead of size() but calculateSize is private, doh :( and no other way to get it from a subclass, or will then lead to scope limitation domino effect, re-doh :( IMHO, calculateSize should be protected, so that it would allow direct redefinition of memory allocation (including easy redefinition of allocateMemory(int)).

JNA has realy gone much further than nlink on native feature support and is much stable on "tricky things" according to my experience. But there are some little things that make nlink still more appealing : - genericity : Did I say this is becoming mandatory nowadays ? You bet it is, for instance toArray would be really simpler.

Mandatory, except if you're using 1.4 :) I see your point, but (Type) object, is more text than the same usage with generics, but not necessarily simpler.

I understand you concern with legacy VM, but given the fact the JDK is now opensourced, I dont't think code should restrict from using new features (especialy when beeing quite usefull and having positive impact on code quality).

- annotation : cool ones are those for name overriding on members and class. This is way more convenient & clean than a lookup Map, IMHO ;-)

I agree, but it's not clear that name overriding is a good idea in the first place.

Can you explain what are the risks, issue or problem you foreseen with name overriding ?

Personally, I think it is a good idea to ease the coding, because sometime OS APIs function name are really, emm... meaningless. And no, don't even ask it, I will not provide example, I won't, I don't like boomerang effect too ;-)

- cleaner Java API integration (for instance using java.nio.Buffer's allocate instead of malloc/free, and less native interraction points between java and native ==> less JNI points opened ==> easier to secure & port )

This is currently under testing on a dedicated branch.

Cool, can't wait to see the "nextGen" :o)

- on win32 by default call to unicode/W methods for method existing in both ascii and unicode (yes, Java is unicode too !)

The tradeoff here is ease-of-use versus control. It would be possible to attempt to auto-map a function name on w32, auto-mapping String arguments appropriately if the -W suffixed function name is found.

Here is what nlink is doing, say you put a method like : GetRawInputDeviceInfo

At "binding time", it first looks if there is an existing function in the library with that name. If not, it looks for a method with same name but adding W suffix. If there is one, you got your "winne", if not throw a big-bad-exception. Simple, efficient

In worst case, making this only happening for windows should be enough to prevent "loss of control", because I don't know any Win32 method (even a Unix method by the way) that ends with W.

- cleaner code (maybe because NLink is Win32 only at this time ?!?), this would ease code understanding

Some specific examples would be helpful.

This is my general feeling digging at both code with a newcomer, fresh and external point of view. Maybe I should have used the word "clearer" instead...

Let's say, the way you map the contraints, the way you use the API, all this look more clean on nlink.

Ok, if you wan't a bleeding edge exemple : malloc from Java is not something I consider clean at all ;-)

Best Rgs, JB