[FIXED] JAWT interface exception on Mac OSX with Java 7

Dahie · December 04, 2011, 16:03:44

Hello everybody

I have a project that is developed with Java7 and using LWJGL as graphics library. I'm developing on Mac OSX 10.7.2 and I have problems executing the application. The stack trace I get is this.

JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
org.lwjgl.LWJGLException: Could not get the JAWT interface
        at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
        at org.lwjgl.opengl.AWTSurfaceLock.access$100(AWTSurfaceLock.java:51)
        at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:94)
        at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:92)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:92)
        at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:66)
        at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:56)
        at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
        at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
        at org.lwjgl.opengl.MacOSXContextImplementation.create(MacOSXContextImplementation.java:47)
        at org.lwjgl.opengl.ContextGL.<init>(ContextGL.java:132)
        at org.lwjgl.opengl.Display.create(Display.java:875)
        at org.lwjgl.opengl.Display.create(Display.java:782)
        at org.lwjgl.opengl.Display.create(Display.java:764)
        at de.master.graphics.render.Renderer3D.init(Renderer3D.java:182)
        at de.master.graphics.render.Renderer3D.start(Renderer3D.java:163)
        at de.master.game.Game.start(Game.java:102)
        at de.master.game.Game.main(Game.java:113)

I get this with LWJGL 2.8.x. I did not try older. As Java7 is not supported natively by apple I installed and tried both the OpenJDK 7 and the Oracle JDK7 (in build 214 and 220). Always the same effect. For the longest time I thought it was some misconfiguration, so I took one of the example projects of LWJGL and tried to run them. I figure they work using the native Java6-JDK, but as soon as I switch to any JDK7 it breaks either with the above stacktrace or this message:

QuoteJavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
GLApp.initDisplay(): Failed to create OpenGL window: org.lwjgl.LWJGLException: Could not get the JAWT interface

Can you help me to get it working and is there any more information I can provide?

kappa · December 04, 2011, 16:29:21

Hi, thanks for testing this and reporting, not sure if Java 7 on OS X has been tested with LWJGL before, since its not officially released yet.

However, does the error go away if you call the following code before making any LWJGL calls.

System.loadLibrary("jawt");

Would help if you can verify the above.

Thanks

Dahie · December 04, 2011, 16:37:21

No change, sorry.

kappa · December 04, 2011, 23:47:16

Still seems that Java 7 on OS X is under heavy development, had a quick go at installing the Developer Preview (b220) on OS X 10.6, however it didn't work properly, complained about being unable to load the natives for the fonts. So unfortunately was unable to reproduce the error, will give it another go after a few more releases.

From the exception you pasted above, System.loadLibrary("jawt"); should have fixed the issue, you sure you ran that before running any AWT or LWJGL methods?

Dahie · December 05, 2011, 08:40:53

I checked again. I did call a JFileChooser before, but nothing else. I moved the LoadLibrary before this, so it was really the first thing execuated in main, but it still did not change anything.

kappa · December 05, 2011, 20:33:30

The error really does look like that its related the jawt native not being loaded. It could be that the library name is not mapped hence why the above solution using the libname isn't working.

Could you try manually locating where libjawt.dylib native is in your jdk folder, then manually load it using System.load.

Something like following might work

System.load(System.getProperty("java.home") + "/lib/amd64/libjawt.dylib");

I'm not sure of the exact path, so you'll have to double check it to ensure it does points to the correct libjawt.dylib in your jdk directory.

If you do get it to work please do report back, so it can be integrated into the library.

Thanks

Dahie · December 06, 2011, 16:06:33

Don't worry, I'm eager to get this working, so I won't give up so soon.

Unfortunately this doesn't bring any difference either. I changed the lib path to: "/lib/libjawt.dylib", which is where the dylib is in both the Java7 Oracle JDK and the OpenJDK. File existance before loading was verified in both cases.

Dahie · December 21, 2011, 16:29:30

With the newest Java7 Developer Build 222 on OSX I get some more error output.

2011-12-21 17:26:13.656 java[665:707] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil
2011-12-21 17:26:13.664 java[665:707] (
	0   CoreFoundation                      0x00007fff9286a286 __exceptionPreprocess + 198
	1   libobjc.A.dylib                     0x00007fff8dba5d5e objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff92811108 -[__NSArrayM insertObject:atIndex:] + 296
	3   AppKit                              0x00007fff90d4c109 -[NSMenu insertItem:atIndex:] + 478
	4   liblwawt.dylib                      0x000000015b8efc14 addMenuItem + 185
	5   liblwawt.dylib                      0x000000015b8ef905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211
	6   liblwawt.dylib                      0x000000015b8efee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227
	7   JavaNativeFoundation                0x000000015afe65fd +[JNFRunLoop _performCopiedBlock:] + 20
	8   CoreFoundation                      0x00007fff928940cd +[NSObject performSelector:withObject:] + 61
	9   Foundation                          0x00007fff8f6dfe44 __NSThreadPerformPerform + 214
	10  CoreFoundation                      0x00007fff927d8b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
	11  CoreFoundation                      0x00007fff927d83bd __CFRunLoopDoSources0 + 253
	12  CoreFoundation                      0x00007fff927ff1a9 __CFRunLoopRun + 905
	13  CoreFoundation                      0x00007fff927feae6 CFRunLoopRunSpecific + 230
	14  HIToolbox                           0x00007fff8b9f63d3 RunCurrentEventLoopInMode + 277
	15  HIToolbox                           0x00007fff8b9fd63d ReceiveNextEventCommon + 355
	16  HIToolbox                           0x00007fff8b9fd4ca BlockUntilNextEventMatchingListInMode + 62
	17  AppKit                              0x00007fff90d353f1 _DPSNextEvent + 659
	18  AppKit                              0x00007fff90d34cf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135
	19  libosxapp.dylib                     0x000000015b98a82c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124
	20  AppKit                              0x00007fff90d3162d -[NSApplication run] + 470
	21  libosxapp.dylib                     0x000000015b98a74b +[NSApplicationAWT runAWTLoopWithApp:] + 156
	22  liblwawt.dylib                      0x000000015b8eddad -[AWTStarter starter:] + 1616
	23  CoreFoundation                      0x00007fff92859a1d -[NSObject performSelector:withObject:] + 61
	24  Foundation                          0x00007fff8f6dfe44 __NSThreadPerformPerform + 214
	25  CoreFoundation                      0x00007fff927d8b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
	26  CoreFoundation                      0x00007fff927d83bd __CFRunLoopDoSources0 + 253
	27  CoreFoundation                      0x00007fff927ff1a9 __CFRunLoopRun + 905
	28  CoreFoundation                      0x00007fff927feae6 CFRunLoopRunSpecific + 230
	29  java                                0x0000000106707cb4 CreateExecutionEnvironment + 841
	30  java                                0x00000001067057b8 JLI_Launch + 1933
	31  java                                0x0000000106709a30 main + 108
	32  java                                0x00000001067033f4 start + 52
)
2011-12-21 17:26:13.665 java[665:707] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil
2011-12-21 17:26:13.667 java[665:707] (
	0   CoreFoundation                      0x00007fff9286a286 __exceptionPreprocess + 198
	1   libobjc.A.dylib                     0x00007fff8dba5d5e objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff92811108 -[__NSArrayM insertObject:atIndex:] + 296
	3   AppKit                              0x00007fff90d4c109 -[NSMenu insertItem:atIndex:] + 478
	4   liblwawt.dylib                      0x000000015b8efc14 addMenuItem + 185
	5   liblwawt.dylib                      0x000000015b8ef905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211
	6   liblwawt.dylib                      0x000000015b8efee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227
	7   JavaNativeFoundation                0x000000015afe65fd +[JNFRunLoop _performCopiedBlock:] + 20
	8   CoreFoundation                      0x00007fff928940cd +[NSObject performSelector:withObject:] + 61
	9   Foundation                          0x00007fff8f6dfe44 __NSThreadPerformPerform + 214
	10  CoreFoundation                      0x00007fff927d8b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
	11  CoreFoundation                      0x00007fff927d83bd __CFRunLoopDoSources0 + 253
	12  CoreFoundation                      0x00007fff927ff1a9 __CFRunLoopRun + 905
	13  CoreFoundation                      0x00007fff927feae6 CFRunLoopRunSpecific + 230
	14  HIToolbox                           0x00007fff8b9f63d3 RunCurrentEventLoopInMode + 277
	15  HIToolbox                           0x00007fff8b9fd58f ReceiveNextEventCommon + 181
	16  HIToolbox                           0x00007fff8b9fd4ca BlockUntilNextEventMatchingListInMode + 62
	17  AppKit                              0x00007fff90d353f1 _DPSNextEvent + 659
	18  AppKit                              0x00007fff90d34cf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135
	19  libosxapp.dylib                     0x000000015b98a82c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124
	20  AppKit                              0x00007fff90d3162d -[NSApplication run] + 470
	21  libosxapp.dylib                     0x000000015b98a74b +[NSApplicationAWT runAWTLoopWithApp:] + 156
	22  liblwawt.dylib                      0x000000015b8eddad -[AWTStarter starter:] + 1616
	23  CoreFoundation                      0x00007fff92859a1d -[NSObject performSelector:withObject:] + 61
	24  Foundation                          0x00007fff8f6dfe44 __NSThreadPerformPerform + 214
	25  CoreFoundation                      0x00007fff927d8b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
	26  CoreFoundation                      0x00007fff927d83bd __CFRunLoopDoSources0 + 253
	27  CoreFoundation                      0x00007fff927ff1a9 __CFRunLoopRun + 905
	28  CoreFoundation                      0x00007fff927feae6 CFRunLoopRunSpecific + 230
	29  java                                0x0000000106707cb4 CreateExecutionEnvironment + 841
	30  java                                0x00000001067057b8 JLI_Launch + 1933
	31  java                                0x0000000106709a30 main + 108
	32  java                                0x00000001067033f4 start + 52
)
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
GLApp.initDisplay(): Failed to create OpenGL window: org.lwjgl.LWJGLException: Could not get the JAWT interface

This is when I run it without any manual loading of JAWT.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=111e09f7f, pid=720, tid=4515852288
#
# JRE version: 7.0-b222
# Java VM: OpenJDK 64-Bit Server VM (21.0-b17 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C  [liblwawt.dylib+0xdf7f]  JNI_OnLoad+0x96
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/danielsenff/Produktion/Java/workspace/ClayLWJGL/hs_err_pid720.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

This is with your proposed manual loading of JAWT. I attached the log.

Hope this gets us further.

Dahie · January 04, 2012, 07:55:42

No change in build 223.

kappa · January 20, 2012, 12:14:45

hmm, looking further into this it seems that the JAWT/NSView API will intentionally not be included in OpenJDK 7 as mentioned here.

Basically this is the mechanism used to embed the OpenGL context on an AWT Canvas. There is a JAWT/CALayer based method inside LWJGL which we can switch on for now to make it work on OpenJDK7+ (used currently only by OS X Plugin2 Applets). However the JAWT/CALayer method does come at a performance cost since it renders to an offscreen context and then render to texture is used to draw it on the AWT Canvas.

In the long run this means that since its not possible to embed a context directly into AWT anymore, the OS X port of LWJGL needs to be completely rewritten using something like Cocoa.

Matzon · January 20, 2012, 17:11:39

\o/

princec · January 20, 2012, 19:40:24

Maybe someone could inform Markus and he might be tempted to spend some of his millions financing the development with a contractor?

Cas

kappa · April 30, 2012, 14:28:34

Any idea's what we can do about this issue?

Oracle have taken over Java development on OS X now and soon their version will be the main OS X JRE. Oracle's version does not support the JAWT/NSView API nor are they likely to add it (as it was based on a hidden Apple exclusive API). There are already reports coming in from early OS X Java 7 adopters that LWJGL no longer works.

OS X 10.8 is also coming out this summer and Oracle Java/OpenJDK 7+ may be the only version of Java that works on there.

So unless something is done soon, LWJGL will not longer work on OS X.

spasi · April 30, 2012, 16:03:52

I think we can start investigating JavaFX integration, via Glass/Prism. I'm not sure if it's technically possible though, we'll have to use internal (com.sun.*) functionality. There's no documentation available, but it's easy enough to decompile and figure out most of it. Not sure if Glass will be part of the open source JavaFX, so we might have to get naughty.

kappa · April 30, 2012, 16:32:11

hmm, the JavaFX windowing system seems cool but not sure how well a fit it'll be for LWJGL considering OpenJFX's GPL nature and the risks of depending on com.sun.*. either way its likely they'll use the CALayer approach. Besides, its not ready for OS X yet (who knows when it will be) and will not be compatible with the Apple JVM.

The reason why AWT is no longer usable is because the only way to draw OpenGL on it now is through the use of a Cocoa CALayer (renders everything to an offscreen image before drawing the final image). However for an OpenGL binding like LWJGL to work, this needs to be done twice! (yes tried to avoid this problem, including with the aid of Apple engineers but it seems to be a technical limitation of the Cocoa API). First LWJGL draws its stuff to a pbuffer and renders it to an image. Second the image is drawn on the CALayer (again to an offscreen buffer) and then finally drawn to the screen. This is pretty much unacceptable and kill performance and has all sorts of other issues. We have this working to an extent for LWJGL Applets on OS X (after some major hackage and pain) but you can understand why this is not really the way to go.

We really need a clean lightweight re-implementation of the LWJGL windowing system on OS X using the Cocoa API directly. Its really the only way to go now on OS X for a simple window with an OpenGL context on it, its future proof (as its Apples API of choice). Any other windowing library like SWT, QT, Prism, etc all probably use Cocoa internally anyway and just add bloat for our purposes. One downside is that Cocoa is an Objective-C library (but its mostly compatible with C) and the only other choice on OS X is Carbon which is Apple's old C API but this is no longer supported by Apple and likely not the way to go as it could get depreciated at any time.

News:

[FIXED] JAWT interface exception on Mac OSX with Java 7