Timothy Wall wrote:
Since it seems to work under your IDE, and it works with the original
jna.jar, but it doesn't work after processing with one-jar.sf.net,
maybe it's the one-jar configuration that is causing the problem?
Since one-jar puts the native library in a different location than
expected by JNA and uses its own class loader to load the native
library, I'd say that's a good candidate for investigation.
Actually the extraction and loading of the library works just fine with
one-jar but I did look further into the DeleteNativeLibrary class and
that's the part that fails with one-jar since it puts library jars on
the classpath specially--basically the runtime exec is doomed to never
find the DeleteNativeLibrary main.
No, it's not an ideal solution. As such, it's even less than ideal to
add complexities to it to handle special cases or custom configuration.
Well I was really trying to suggest an alternative approach which
doesn't actually change any JNA API but allows an application developer
the opportunity to be fully in control of the files written out while
its running. My contribution didn't change anything for those user's
that don't set the System Property... But it does allow certain
developers who read more documentation the ability to have more control
over the filesystem altering behaviour of their application. (And to
avoid initializing a second JVM instance to delete a single file.)
Otherwise I guess I'm left with the prospect of altering all of my
different platform deployments to ensure the JNA native bits are
accessible on java.library.path which is not nearly as attractive.
4 messages in net.java.dev.jna.usersRe: [jna-users] Jnidispatch Library I...
