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?
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
No change, sorry. :(
Still seems that Java 7 on OS X is under heavy development, had a quick go at installing the Developer Preview (b220) (http://jdk7.java.net/macportpreview/) 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?
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.
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 workSystem.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
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.
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. :)
No change in build 223.
hmm, looking further into this it seems that the JAWT/NSView API will intentionally not be included in OpenJDK 7 as mentioned here (https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port+Project+Status).
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.
\o/
Maybe someone could inform Markus and he might be tempted to spend some of his millions financing the development with a contractor?
Cas :)
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.
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.
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.
JavaFX 2.1 comes bundled with JDK7u4 and is available now for both Windows and MacOS. AFAIK, it will be pushed to all MacOS users in early May. In 2.2 applet/JWS support will also be added (on MacOS).
Anyway, a clean Cocoa solution would be cool for standalone, but it's still going to be half-arsed for applets. A JavaFX solution would also be beneficial for the other 2 OSes, since we'll have to integrate with it sooner or later.
Btw, are you saying that JavaFX applets will be going through the same slow rendering path?
Quote from: spasi on April 30, 2012, 16:50:46
Btw, are you saying that JavaFX applets will be going through the same slow rendering path?
Yes they'll have to, as CALayer is the only way to draw in a browser on OS X now (even Flash, Unity3d, etc have moved to it). The Oracle engineers might even decide to use the CALayer as the only method and take a bit of a performance hit for standalone JavaFX application. Do note if you have direct access to the Cocoa API (like Unity3D, Flash and probably JavaFX) then you can avoid the double performance hit as you can use the CALayers OpenGL context directly (which would run at acceptable speeds) unlike through JAWT where its hidden to LWJGL and we need to use the slow pbuffer trick to make it work (which is really the major performance killer).
OK, then it makes sense to go with Cocoa now and consider JavaFX integration later, when it has matured a bit.
It's really got to be done properly I think using the Obj-C APIs or it's just going to remain fragile. But has anyone frequenting here got any proper OSX Obj-C development experience?
Cas :)
Contracting out the task looks like the way to go, at least for those with a financial interest in LWJGL on OS X.
We'll need someone who has the following skills:
Solid Knowledge: C, Java, Objective-C, JNI, Cocoa and OpenGL.
Basic Knowledge: SVN, ANT, Carbon.
In-depth knowledge of Cocoa and its threading model is required as it is pretty tricky to get a standalone Cocoa app running through JNI plus we probably want the application to be nibless (to at least allow easy building on the nightly server). Knowledge of OpenGL with both NSView and CALayer(NSOpenGLLayer) is recommended. NSView will probably be the main way to render but we'll probably want the CALayer option too to allow embedding in AWT (for stuff like Applets, Display.setParent, etc). There is already a surprising amount of Cocoa/Objective-C in the current code base so should be useful in some way.
The LWJGL Display does do a few things which are not supported by the Cocoa API (like mouse grabbing, etc) using the Carbon API, these bits can just be reused from existing code base to keep the functionality. Knowledge of OpenGL contexts is also vital as that part is mostly done in C in LWJGL to allow code sharing between platforms. So mostly it will be a task to replace all the AWT window parts with a pure Cocoa window implementation.
Target Platform: Support for OS X 10.5+ on both 32bit and 64bit systems (time we really dropped PPC, OS X 10.3 and OS X 10.4).
I reckon someone with enough skill should be able to wrap it up in about 2 weeks, thereafter idling for a few weeks on the forums to fix any reported bugs.
Hmm where would be the best place to advertise it? Ideally a volunteer with a vested interest would be able to do it.
Cas :)
JGO would be a good place to start, could also reach some wide coverage through twitter with some targeted tweets.
Wonder if some of the old LWJGL contributors like elias naur or kevglass would be interested in some contract work or something (both have solid expertise in the required areas). Other experienced Java vets like David Brackeen (http://www.pulp.io/) (does contract work) might be interested but who knows, will really depend on what we have to offer.
I'll ask Kev.
Cas :)
http://www.puppygames.net/blog/?p=1112
Cas :)
Are you looking for someone to basically implement this
https://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html
?
Seems to have all the things you are interested in, using objective c, NSView etc
I have a Mac with xcode, know java and jni but not so hot on the object c side of things
I took a look at the original problem and I have some more info.
"JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM"
The message is comes up due to the fact that your lwjgl native libraries were built against the 1.6 apple jre. If you are trying to use the jdk7 jre with these incompatible native libraries, you will receive that error. It's telling you that the 1.6 apple environment has not loaded yet, which is unfortunate but expected behavior.
I pulled jdk7u and built the lwjgl native libraries against it (after some hacking). My app launched a window, but the content area with my opengl surface was blank. To make a long story short, lwjgl will not work with jdk7u at all.
The long term solution is to implement a native cocoa window in lwjgl. For the short term, getting lwjgl compiling and functioning (even if there is performance problems) would be a good idea.
I certainly have the skills and the interest to do this work, but my time is somewhat limited with family, job, etc. I will try to look into the solution this week (hopefully).
Dan - that'd be great. Let us know when you're ready to start.
Cas :)
Cas: "Aha, Mojang have woken up… there is progress inching forward in this area."
Ahh great news!! :) I got really scared that lwjgl on osx is in trouble.
I wish I knew enough of java to help...but I don't :(
Any news on this yet? I'm running into the same issue now :/
Additionally I too could offer help in this area. I have Java, JNI, Xcode, Obj-C and OpenGL/LWJGL experience but I'm not really a seasoned OS X developer. I've ported/created quite a lot of code to Obj-C/iOS last year for my day job though (this was Security/UI related stuff and not OpenGL/Graphics related at all, unfortunately).
Just checking in on progress? are there people actually working on this? I wouldn't mind trying to help out on this, is there any help on what needs to be re written? I've had a look at the code and can see where the old context code is loaded, should the java part of it work more like Linux and windows now?
In ContextGL.java there is
properties.put(APPLEGLSharing.CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE).put(CGLShareGroup);
but for windows and linux there is a context property and a display. I don't know how this is used to know exactly whats required.
Not sure what the current progress is however last I heard, UltraMoogleMan from #LWJGL was looking into it, if you do want to help best to liaise with him. As for what needs to be done, mostly the AWT part needs to be replaced with a pure Cocoa implementation.
I'm using a slick/lwjgl AWT game canvas inside a Swing container/UI. Does this mean I won't be able to use this AWT canvas in the future (since it will be cocoa based)?
Players of my game running Windows with jdk7 are running against this bug http://lwjgl.org/forum/index.php?topic=4217.0, but I'm on Mac and I'm trying to reproduce things and getting it work with openjdk 7 to reproduce it (since normal jdk 7 isn't supported for mac os x 10.6).
Maybe I should just throw away my mac instead.
nah, just the native display code will be written in cocoa, the AWT stuff should continue to work as normal (in fact AWT on OS X is internally also written in Cocoa).
Oh, great! I kinda misunderstood that :D
I'm in sore need of this as well. Any word on progress? I would look into this myself, if time were on my side. But it isn't.
It's pretty upsetting (damnation, Oracle!) considering I've just put in a day and half trying to figure out why my code won't run on OS X 10.8 with either Java 6 or Java 7... I first had to restructure from hybrid OpenGL 2 & 3 issues (which were non-issues under Win7) for OS X 3.2 core profile, and now I found out it was all in vain.
Quote from: Nick Wiggill on November 26, 2012, 20:28:39
I'm in sore need of this as well. Any word on progress?
Yes, have a read of this thread (http://lwjgl.org/forum/index.php/topic,4711.0.html).
Hi,
In the meantime, is there any workaround? I am trying to play Minecraft on Mac OS X 10.8 and the game just fails to start. Even after updating LWJGL used by Minecraft, the same problem persists. I cannot believe that every Mac user wanting to play Minecraft has now to install Windows or some flavor of Linux on their machine! Well, I am starting to believe many advanced users cannot live with just Mac OS X, which is too basic and restrictive (mainly GUI over-simplifying things), but I would like to dig further to be sure of that.
This issue should be fixed now and will be part of the next LWJGL release (LWJGL 2.9.0), In the mean time try the nightly builds of LWJGL from here (http://ci.newdawnsoftware.com/job/LWJGL-git-dist/).
Anyway marking this as fixed, keep an eye on this thread (http://lwjgl.org/forum/index.php/topic,4711.225.html) for any remaining issues.
Hello,
I am Basilio and I am new in the forum.
I would like to know if the issue is solved with OSX and Java 7.
This is because I am trying to use vlcj for Java but I cannot get it to work.
Thank you very much for your help,
all the best,
Basilio