Java AWT/Swing is effectively single-threaded. Requests that execute
against Java GUI components often need to execute on the Java GUI
event loop thread.
We have a large number of object interfaces that must execute on the
Java GUI thread but are dispatched by the Java POA on a POA pool thread.
(it is not possible for us to dispatch each method call individually to
the GUI thread within each object implementation)
We can use a Tie class to dispatch each invocation to the Java
GUI thread, but then we get an exception because com.sun.corba.se.internal.POA.POACurrent.peekThrowInternal() uses
a ThreadLocal stack of InvocationInfo objects, and the GUI thread
does not have the stack; only the original POA thread has it.
We can fix this by creating (within a Tie class) the appropriate
InvocationInfo object on a ThreadLocal associated with the GUI thread,
populating it within info from the POA thread's stack,
and then popping it before returning to the regular POA dispatch
We have developed a simple fix that exposes (makes public)
three methods on POACurrent: addThreadInfo(), removeThreadInfo(),
peekThrowNoContext(). We do not believe this is likely to be
an acceptable solution so we would like to work with the
java-idl team to identify a better one.
The attachment AccessibleImpl.java contains our Tie-proxy class
AccessiblePOATieProxy; this shows how we dispatch the
invocation to the GUI thread (in real_invoke, we use
SwingUtility.invokeAndWait() to execute a command
AWTInvocation. The calls to the (formerly) private Java IDL
methods are in this method and in AWTInvocation.run().