 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
6 messages in net.java.dev.jna.usersRe: [jna-users] Pointer to structure ...| From | Sent On | Attachments |
|---|---|---|
| Jean-Baptiste Bugeaud | May 16, 2007 7:08 am | |
| Timothy Wall | May 17, 2007 10:40 am | |
| Timothy Wall | May 17, 2007 11:20 am | |
| Jean-Baptiste Bugeaud | May 18, 2007 5:55 am | |
| Timothy Wall | May 18, 2007 6:51 am | |
| Jean-Baptiste Bugeaud | May 18, 2007 1:11 pm |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread 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: | Timothy Wall (twal...@dev.java.net) | |
| Date: | May 18, 2007 6:51:59 am | |
| List: | net.java.dev.jna.users | |
I've filed an issue for this.
https://jna.dev.java.net/issues/show_bug.cgi?id=16
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.
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.
- 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.
- 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.
- 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.
- cleaner code (maybe because NLink is Win32 only at this time ?!?), this would ease code understanding
Some specific examples would be helpful.