On Feb 4, 2008, at 5:56 PM, Charles Smith wrote:
Hello,
Recently I have been integrating JNA into our java application to
give us access to the Recylce Bin and other niceties in Windows.
When I was finished I noticed that sometimes the jnidispatch.dll
that JNA extracts to my temp folder on Windows is left behind even
though the VM exits cleanly. I tested it further and noticed that
it worked fine when running in my IDE but not when packed up in a
jar (we use one-jar.sourceforge.net for our jar).
After looking into the handling of the native lib extraction in the
Native class and DeleteNativeLibrary class I realized that it might
be a timing issue when the VM is shutting down. Perhaps in certain
cases one second is not a long enough time for the previous VM to
release its lock on the tempfile and so the DeleteNativeLibrary
main fails to do its job...
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.
Since the DeleteNativeLibrary class is not an ideal solution I've
been pondering whether it might be better to ...
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.
4 messages in net.java.dev.jna.usersRe: [jna-users] Jnidispatch Library I...
