I've tweaked the shutdown process to attempt a forced unload of the
native library which should work in most circumstances (at least with
a Sun VM), avoiding the need for a separate file deletion VM launch.
On Feb 5, 2008, at 5:46 PM, Charles Smith wrote:
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...
