JAWTWindow: Non intrusive workaround for Bug 1004 and providing AppContextInfo to mitigate related bugs, e.g. Bug 983

Bug 1004, as well as Bug 983, are caused by issueing certain AWT tasks
from a Thread which ThreadGroup is not mapped to a valid sun.awt.AppContext (AppContext).

The 'certain AWT tasks' are all quering the current EventQueue instance,
which is associated to the AppContext.
This operation will fail and cause a NullPointerException.

This workaround simply gathers a ThreadGroup
which is mapped to the desired AppContext.

This AppContext ThreadGroup is being used to launch a new Thread
which is then mapped to an AppContext and hence can issue
all AWT commands.

+++

In the Bug 1004 scenario, JAWTWindow is constructed
from within the AWT EDT, which ThreadGroup does belong to the AppContext.

Here the issue is that an AWT operation was invoked from the OSX main thread,
which itself does not belong to the AppContext.
The workaround as described above solves this issue.

+++

For Bug 983 the scenario is different, since JAWTWindow is _not_
constructed from a thread which ThreadGroup is mapped to the AppContext.
[It is also not constructed on the AWT-EDT].

It is recommended to have Java3D gathering the AppContextInfo itself early
and issues the JAWTWindow creation on an eligible thread using
AppContextInfo.invokeOnAppContextThread(..)
similar to JAWTWindow.attachSurfaceLayer(..).

This will allow removing the more intrusive remedy
of Java3D commit bdda2ac20bfef85271da764d1989ec3434d5c67a
and simply issuing the crucial commands on a proper thread.

+++

The more intrusive workaround of above commit
does not work in general at least for Bug 1004 (OSX and Applets).
While forcing the mapping of the 'alien' thread-group
to the AppContext work for the 1st launch w/ the 1st AppContext,
a second launch w/ a new AppContext will fail.

Here we did update the new AppContext knowledge in AppContextInfo,
however a NPE is received in getEventQueue() .. since the AppContext
is gathered after patching, but the EventQueue is still null.

Further more, using static knowledge of AppContext/ThreadGroup mapping
violates at least the Applet lifecycle. Here we can have one ClassLoader
with multiple AppContext - i.e. Applets.

0 files changed, 0 insertions, 0 deletions