We have some proprietary libraries we need to interface with. These libraries are Windows DLLs, or Linux .so files. We got the headers to define the interfaces. Since I have never done anything with native l开发者_如何学编程ibs, I looked at JNAerator (http://code.google.com/p/jnaerator/) and the BridJ and JNA stuff.
What's a simple way to use a C++ header file and the compiled lib to generate an interface? For example, by adopting JNA in general with something like:
SomeDLL lib = (SomeDLL) Native.loadLibrary("some_dll", SomeDLL.class);
I have to keep the DLL somewhere: how do I bundle the DLL with the Jar? I use Maven to build the Jar file... but the Native.loadLibrary interface doesn't allow to directly specify a path.
JNI coding is usually a manual process of writing C++ code to create the native glue methods. There's an entire book that explains it.
In some cases, http://jna.java.net/ can automate or accelerate this process, but don't count on it.
You can't 'bundle the native libraries' unless you go down the path of using OSGi or something like the Tanukisoft packaging tool, there's no built-in feature for that purpose in Java.
You connect the dots by using -Djava.library.path to tell java where to find native libraries, or using the lower-level APIs to System.loadLibrary that allow you to specify a full path.
Watch out for interactions with PATH and LD_LIBRARY_PATH if your native libraries have dependencies in turn.
With BridJ, you can bundle the DLL/.so/.dylib just fine with the JAR, but you have to put it (or them) in a specific platform-dependent path within the JAR, which starts by "org/bridj/lib/" and ends with a platform+architecture identifier.
Here's BridJ's own source tree, which exhibits this native bundling scheme : org/bridj/lib resource directory
If you stick to this convention, you won't have do deal with PATH, LD_LIBRARY_PATH or file extraction : BridJ.register()
(called on a @Library
-annotated class with native methods) will do it all for you !
精彩评论