Bug 1004

+++
java.lang.NullPointerException
	at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:1003)
	at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:998)
	at sun.awt.SunToolkit.getSystemEventQueueImpl(SunToolkit.java:993)
	at java.awt.Toolkit.getEventQueue(Toolkit.java:1749)
	at java.awt.Component.repaint(Component.java:3405)
	at java.awt.Component.repaint(Component.java:3305)
	at com.jogamp.nativewindow.awt.JAWTWindow.attachSurfaceLayer(JAWTWindow.java:335)
	at jogamp.opengl.macosx.cgl.MacOSXCGLContext$NSOpenGLImpl$AttachGLLayerCmd.run(MacOSXCGLContext.java:726)
	at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:95)
+++

Similar, if not equal, to Java3D Bug 983

Maybe we can copy the _workaround_ applied to Java3D, 
Bug 983 Comment 9, to JOGL's JAWTWindow ?

+++

Also see forum thread:
  <http://forum.jogamp.org/Jogl-2-stops-working-on-Mac-after-Java7-update-55-tp4032286.html>

+++

(In reply to comment #1)
> +++
> java.lang.NullPointerException
> 	at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:1003)
> 	at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:998)
> 	at sun.awt.SunToolkit.getSystemEventQueueImpl(SunToolkit.java:993)
> 	at java.awt.Toolkit.getEventQueue(Toolkit.java:1749)
> 	at java.awt.Component.repaint(Component.java:3405)
> 	at java.awt.Component.repaint(Component.java:3305)
> 	at
> com.jogamp.nativewindow.awt.JAWTWindow.attachSurfaceLayer(JAWTWindow.java:
> 335)
> 	at
> jogamp.opengl.macosx.cgl.MacOSXCGLContext$NSOpenGLImpl$AttachGLLayerCmd.
> run(MacOSXCGLContext.java:726)
> 	at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:95)
> +++
> 
> Similar, if not equal, to Java3D Bug 983
> 
> Maybe we can copy the _workaround_ applied to Java3D, 
> Bug 983 Comment 9, to JOGL's JAWTWindow ?
> 
> +++
> 
> Also see forum thread:
>  
> <http://forum.jogamp.org/Jogl-2-stops-working-on-Mac-after-Java7-update-55-
> tp4032286.html>
> 
> +++

Further references:

  <http://stackoverflow.com/questions/17223304/appcontext-is-null-from-rmi-thread-with-java-7-update-25>

  <http://stackoverflow.com/questions/17275259/nullpointerexception-in-invokelater-while-running-through-java-webstart/20102779#20102779>

(In reply to comment #2)
> Further references:
> 
>  
> <http://stackoverflow.com/questions/17223304/appcontext-is-null-from-rmi-
> thread-with-java-7-update-25>
> 
>  
> <http://stackoverflow.com/questions/17275259/nullpointerexception-in-
> invokelater-while-running-through-java-webstart/20102779#20102779>

Oracle's bug reports:
  <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8019274>
  <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8019272>

Note:
  "SQE-OK to defer this issue to 7u60/8u20"

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.

gluegen f39100b35d0833764f2220e487ea7ea05ed87352
jogl aa1c04ebee23d0803880d6d68ae73109c1a5c178

signed test build are available here:

http://jogamp.org/deployment/archive/master/gluegen_786-joal_532-jogl_1249-jocl_959-signed/

http://jogamp.org/deployment/archive/master/gluegen_786-joal_532-jogl_1249-jocl_959-signed/jogl-test-applets.html

@David: Can you please confirm, i.e. verify ? Thank you!

Others may verify this issue as well, thank you.

Verified this fix in Java 1.7.0_55 and Java 1.8.0_05.

@Sven: Thank you very much for looking into this and resolving it. We'll look forward to the next JOGL release containing these changes.