Merge pull request #17 from andreyrmg/master

Retrieving a variant type of SAFEARRAY
Fixed issue 19 by handling unexpected Object.wait() wakeups
Fixed issue within COM4J.loadNativeLibrary() where it will fail with a
java.lang.ExceptionInInitializerError if the com4j JAR file is located
within an UNC path.  Within that class, it will take the resource URL of
COM4J.class (for example,
jar:file://host/share/foo/lib/com4j-20120426-2.jar!/com4j/COM4J.class)
to generate the path for the DLL to be extracted to.  In the example
above, it will come up with the path of
"\host\share\foo\lib\com4j-x86.dll", which is invalid.  This fixes the
problem and returns a path starting with "\\host\share...".

Note:  The root cause of the ExceptionInInitializerError is actually:
Caused by: java.lang.NullPointerException
	at com4j.COM4J.loadNativeLibrary(COM4J.java:567)
	at com4j.COM4J.<clinit>(COM4J.java:522)
	... 7 more
It's actually not accurate, and it caused by the use of the LOGGER
static variable before it's initalized.  Though that only caused a less
meaningful stack trace, as the next step in the code should throw an
UnsatisfiedLinkError.  This is also fixed by moving the static LOGGER
initialization to right before the static block that calls
loadNativeLibrary().
Merge pull request #23 from martian111/issue-22

Fixed Issue #22: COM4J.loadNativeLibrary() fails with ExceptionInInitializerError when com4j JAR is on UNC path
Removed IDE project files
Added safeguard against reuse as pointed out by mpoindexter.

Caching of Task is dubious in value, so perhaps we should remove that independent of this change.
Merge branch 'pull-20'
Removed IDE managed files.
doc improvement
doc improvement
Fixed issue #21.

The problem here is that, as @reboot pointed out, when we call "ref.clear()",
it prevents the reference from getting enqueued. So they stick around forever
in ComThread.liveComObjects even though they are actually dead.

I think this fix is simpler than the proposed fix from @guykv in
https://github.com/kohsuke/com4j/pull/21. The added delay in updating
ComThread.liveComObjects is a non-issue because NativePointerPhantomReference
does not own any sizable objects native or Java.

This regression was introduced in b5143cebdcc25110f54a3e7ea02bb12d8d449a65.
See 33e03e862d8f5ab635337d28c939f226e85108ec for the discussion that led to it.
Revert "Removed IDE managed files."

This reverts commit 52508149904c471cd465d3a61dc81b87e6a43493.
Revert "Removed IDE project files"

This reverts commit b14e2a57a9f5ef000a4293a5dfadc4f044e9af0f.
Adding top-level POM and moving site
Updated
Mavenizing runtime
Mavernizing tlbimp
Removing IDE project files
massaging POM
massaging POM