 | 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: |
5 messages in net.java.dev.jna.usersRe: [jna-users] libffi in "a sad state"?| From | Sent On | Attachments |
|---|---|---|
| Charles Oliver Nutter | Sep 3, 2007 8:27 am | |
| Wayne Meissner | Sep 3, 2007 9:46 am | |
| Albert Strasheim | Sep 3, 2007 9:54 am | |
| Charles Oliver Nutter | Sep 3, 2007 10:21 am | |
| Timothy Wall | Sep 3, 2007 11:07 am |
| 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] libffi in "a sad state"? | Actions... |
|---|---|---|
| From: | Wayne Meissner (wmei...@gmail.com) | |
| Date: | Sep 3, 2007 9:46:29 am | |
| List: | net.java.dev.jna.users | |
Charles Oliver Nutter wrote:
I've had a couple associates comment on libffi not being an active, maintained project any more. Some have raised concerns about JNA using libffi. Here's one set of commments from IRC:
[08:34am] sanxiyn: Re: JNA. libffi seems to be in a sad state. [08:36am] sanxiyn: Many people use it, but the "upstream" development is stagnant and the result is many "local copies". [08:38am] sanxiyn: For example, in Python world, there are *two* forks of libffi. [08:39am] sanxiyn: This is libffi fork of ctypes: http://svn.python.org/projects/python/trunk/Modules/_ctypes/ [08:39am] sanxiyn: And libffi fork from pyobjc: http://svn.red-bean.com/pyobjc/trunk/pyobjc/libffi-src/ [08:39am] sanxiyn: Modifications include Windows 32/64/ce support and ppc64, darwin support. [08:43am] sanxiyn: Rubinius is using C/Invoke: http://www.nongnu.org/cinvoke/
Thoughts? And as far as windows goes, does JNA have any issues to worry about right now?
libffi is still developed as a part of gcc - JNA uses libffi from gcc-4.2.0 with a couple of config files dropped in to make it build outside the gcc tree. No other modifications means we can drop in a later version in a matter of minutes (assuming they don't change the API).
libffi is definitely not perfect - I found a few gotchas/bugs during the port where it does things you don't expect (all strangely on sparc) - but its a lot better than a bunch of handrolled asm.
In the worst case, where we found that libffi had some major bug we couldn't fix, or we wanted to move to an arch that libffi did not support, switching the backend again isn't that hard.
C/Invoke looks interesting, but it doesn't seem to be much more active than libffi development. I could probably add a C/Invoke backend as an alternative in a couple of days, but until I have a compelling reason, I probably won't. (unless say Sun were to buy me a new macbook pro as an enticement, then it'll get done quick smart :-)
For x86/x86_64 (i.e. 99% of the userbase), libffi seems rock solid. I've been using the V3 branch during gstreamer-java development for about 3 months now, and haven't hit any problems on x86 or amd64 (apart from 32bit-isms in JNA itself - but they're all fixed now).
Concerning Windows, Timothy will have to answer that. I don't test under windows much - I just run the unit tests and gstreamer-java examples.
So in summary: - it seems to work fine on the arches we have tested on. - if it does break we can most likely fix it. - if we can't fix it, then its somewhere between a couple of days and a week to switch to C/Invoke as a backend.