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 the DeleteNativeLibrary class is not an ideal solution I've been
pondering whether it might be better to also provide JNA users the
ability to specify their own file to extract the native library to
through a System Property. The simplest way JNA users could make use of
this property would be to set it to a static file in their own
application's directory in the user's profile (user.home). In this way
JNA users can maintain an easy distribution mechanism (a single jar with
no requirement to alter java.library.path) and also ensure that no stray
files are being left behind on the user's system.

I altered the Native.loadNativeLibary() method to acheive this while
still failing back to the temp dir extraction: