(In reply to comment #20)
> 4. Find a VM independent mechanism for detecting a deadlock that doesn't
> require modifying code outside of the binding.

I suspect this is impossible given that there are conditions that temporarily
look like a deadlock but aren't such as tryLock(). You won't really know if
it's using a short timeout or an infinite timeout. An obscure locking process
could use Thread.sleep() or Thread.yield() while repeatedly checking a
condition.

I'd suggest allowing it to deadlock and fix all the bindings. Return a
TEMP_FACTORY for the simple case involving the same Thread and consider
everything else to be a bug in the binding code.

If your StaticLoggerBinder could take a long time to initialise then create a
background Thread instead of doing it in getSingleton().

For compatibility with existing binding code, increment the API version so that
it can return TEMP_FACTORY instead of causing a deadlock. This would be
identical to what it does now.