summaryrefslogtreecommitdiffstats
path: root/make/config/nativewindow/win32-lib.cfg
diff options
context:
space:
mode:
authorSven Gothel <[email protected]>2014-05-12 01:07:34 +0200
committerSven Gothel <[email protected]>2014-05-12 01:07:34 +0200
commitaa1c04ebee23d0803880d6d68ae73109c1a5c178 (patch)
treee050c807ad1ba68ee1bc49be742c4fe9bf1cf71e /make/config/nativewindow/win32-lib.cfg
parentf4d15c7f664d8048ada6ef39f99818062a6701b4 (diff)
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.
Diffstat (limited to 'make/config/nativewindow/win32-lib.cfg')
0 files changed, 0 insertions, 0 deletions