Sim, Thanks for the info, after brief review, JNA looks like a much
better replacement for JNI, it can access native libraries directly from
Java, so would reduce maintenance and C multi platform Make file issues
associated with JNI.
JNA is available at https://jna.dev.java.net/
It is licensed under LGPL v2.1 or later, so can be a platform
requirement, although we cannot distribute it with River, we can write
code utilising it.
Looks like we can utilise JNA proxy's to write library calls for PAM on
Unix / POSIX / Linux / BSD / OSX etc and something different on
Windows. Need something to wrap them up in like an SPI.
Cheers,
Peter.
Sim IJskes - QCG wrote:
On 13-05-10 18:49, Craig L Russell wrote:
My understanding is that you need to start the VM with the knowledge of
where all the jni libraries are. You can either put them into the
"standard" place (varies by platform) or in a special place and name
that special directory using the -Djava.library.path system property
when you start the VM. It doesn't work to set the system property after
you start the VM.
We could study how JNA solved this. It looks like a very deployment
friendly solution for native bindings.
Gr. Sim
