|
From: Wayne M. <wme...@gm...> - 2007-09-03 17:18:14
|
Frank Wierzbicki wrote: > On 9/3/07, Frank Wierzbicki <fwi...@gm...> wrote: > >> If we make it pluggable the way we do with readline, I'd say we can >> just see where it goes and give it a try. If it turns out that we >> can't distribute jna.jar -- we can hopefully have simple instructions >> (much simpler than the readline instructions since there is no compile >> step). Also, if it is written in a pluggable style, we might >> eventually find a BSD licensed jar that we could use instead so that >> distribution ability is unambiguous. > So I took another look at JNA, and it looks like it will need to get > distributed with some os-specific code. While this doesn't kill the > idea -- I think it puts it squarely into the area of being an optional > plugin, since there will need to be one for each os. JNA supports and comes with binaries for most of the operating systems the Sun JDK supports - linux/i386, linux/amd64, win32, macosx/ppc, macosx/i386, solaris/x86, solaris/sparc, solaris/sparc64, freebsd/i386. Windows/amd64 and solaris/amd64 are the only exceptions I can think of. But regardless of that, you probably still want to make it pluggable so when something better comes along (which always happens in software development) you can switch to that. Other options are using C/Invoke http://www.nongnu.org/cinvoke/index.html or libffi and writing enough java/JNI to interface with it. When called from jython, the JNA API is pretty narrow - only a handful of methods. You could abstract them, use a JNA backend initially, then switch to a BSD-licensed backend when you have one ready. |