[FIXED] OSX / Java 7

[normen]

Hi.

Since Oracles Java7 for OSX is soon available even as a JRE with Java7 update 6 (due shortly, preview here) and as a JDK for some time now we (the jMonkeyEngine Team) started playing with it.

Oracle goes back to the "dylib" suffix instead of "jnilib" but with the appropriate querying of the system suffix we were able to extract the file with the correct name in our natives extraction system so it in fact loads the lwjgl binaries without problems. When using an off-screen context and painting the result back to awt we also managed to get the rendering engine to work.

However the canvas implementation as well as the "normal" main window of lwjgl fail under Java7.

This is the error of an app using the main window:

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:57)
	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 com.jme3.system.lwjgl.LwjglDisplay.createContext(LwjglDisplay.java:137)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:113)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:205)
	at java.lang.Thread.run(Thread.java:722)

Any thoughts on this?

Cheers,
Normen

[princec]

Ni Normen,

LWJGL is completely broken under OSX Java 7, and needs a ground-up rewrite of the Display implementation. There have been mutterings about people working on this but as yet, no confirmed progress or even so much as a commit to SVN. There was some hope that Mojang were going to contribute to it as they've got tons of money tied up in it and will suffer a veritable shit/fan interface situation if they don't get it done before it's offered on general release but ... still no news.

Cas

[normen]

Alright, thanks for the info.. Might be I'll have to rig up a build environment for lwjgl/avian some time for iOS support for jME.. But thats definitely a thing of the future.. Maybe I'll find time to at least have an OSX build going with Java7.. But that'll be some research for me as I never built lwjgl yet and I have no idea how the JDK is tied in.. So no use to wait for me in this matter I either guess

[abcdef]

I've been one of those people muttering about helping out on the osx thing, although I have the code and can see the OSX items it would be good to get some of the other developers to provide some of their insight on what needs to be done. By that I mean, where are the java interface points that need to be taken in to concideration (ie what methods are the start points for where the work needs to be done), what c files need to be scrapped and replaced. I've done a bit of research on this and have a good idea of how to get AWT and JNI to work in cocoa and also how to get opengl context's but I have no idea where it needs to be plugged in and what needs to be passed back to the java code.

[normen]

I guess starting with those that appear in the exception is a good idea If you have some instructions on how to set up lwjgl, that'd probably help me and others to have a look too.

[abcdef]

I saw the stacktrace  But wanted to get a complete picture before playing around. I guess could do it via trial and errorto start with

In terms of setup what do you mean? Do you mean how to build it? So far I have just checked out the SVN, there are some ant scripts there for building the natives. I'm not an expert on building the natives though.

I'll have a play around tonight and see if I can build whats there, and see if I can replace some code in the below area's.

        at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:57)
	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)

I'll reply here with some compile help and how I am getting on. I have no idea how to commit back to the repository (unless anyone can put commits back)

[abcdef]

So

After getting the code from SVN

http://java-game-lib.svn.sourceforge.net/viewvc/java-game-lib/

I ran the command ant in

/java-game-lib/trunk/LWJGL

ant -v

(-v gives you some verbose to help debug errors, remove it if you don't need to see everything)

You will need to edit

/java-game-lib/trunk/LWJGL/platform_build/macosx_ant/build.xml

to change gcc-4.2 to gcc and to remove the ppc compile and link sections (as xcode no longer supports it)

At the moment it complains about OpenGL/gl.h and some other headers in context.m (it bombs out in the compile native stage) but I haven't had time to fix it

The way to use cocoa for AWT and opengl is documented in the link below

http://forums.macrumors.com/showthread.php?t=900661

just need to know where to plug everything in to, I think context.m needs editing and the classes here

at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:57)
	at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)

but I haven't got the current code to compile yet so haven't bothered to try and make any code changes. But its a start.

Anyone feel free to add information or tell me I am talking rubbish  more people that can help the better!

[kappa]

@abcdef Do keep in mind that AWT is main reason LWJGL no longer works in Java 7. Previously we were able to get a Cocoa NSView from an AWT Canvas and stick an OpenGL context on it (NSOpenGLContext). This has changed in Java 7 (thanks to Apple) and it is no longer possible because AWT/Swing components are no longer heavyweight and are now lightweight (i.e. AWT Canvas's are no longer Cocoa NSView's).

There was a new AWT API added by Apple in an attempt to fix the above limitation which allowed a CoreAnimation Layer (e.g. NSOpenGLLayers) to be added to an AWT Canvas. However this brought its own set of problems (as seen with our LWJGL applet support on OS X Java plugin2) and not really the best way to go for an OpenGL binding.

Hence the most viable solution is to scrap AWT altogether and rebuild the LWJGL OS X Display implementation from scratch using pure Cocoa and Java JNI. In practice though many bits of the current LWJGL OS X implementation can be reused in a new implementation as some bits are already using Cocoa.

[abcdef]

So just need to basically implement

http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8

?

And hook it in to lwjgl framework?

[kappa]

Yeh you could say that. A basic window with keyboard, mouse and an OpenGL context needs to be written in Cocoa. This should have all the features of the Display, Mouse and Keyboard classes which isn't much and mostly about matching the Cocoa API's to the Display ones. The features of the above should be connected to Java via JNI, there might be a little fiddling needed here with the Java thread and Cocoa thread to get it to work but should be easy if you're familiar with both.

There are a tiny amount of API's not available in Cocoa (e.g. grabbing the mouse) and are currently done in the LWJGL codebase using a bit of Carbon, this code can pretty much be copied over to any new implementation to preserve those features.

Lastly we'll probably need to add/keep support for the JAWT API that uses a CoreAnimation Layer as detailed in this thread. This won't be used at all for standalone LWJGL application but needed for allowing LWJGL to be embedded in AWT (Display.setParent() and AWTGLCanvas, e.g. for allowing LWJGL use in Applets and other AWT/Swing Applications). This is already implemented in the current codebase (was added to support plugin2 applets) but could use a little further looking at and polishing up.

So not too difficult a task if you are familiar with Cocoa, Java JNI and some C but will require some time and effort to implement.

[abcdef]

Thanks, lots of good info there. Will start on the window part first. I'm not a cocoa expert but I understand the documentation code well enough to have a try.

A question on the build front, how are the Mac components build now? Are they built on a mac? The build.xml in the natives section needs a bit of work I think. The ppc compatible gcc is now fully depricated in 10.8.

Also can this problem not be solved by using a similar strategy to the linux code? I've seen other opengl programs work just fine which are written in c/c++ rather than objective c

[kappa]

A question on the build front, how are the Mac components build now? Are they built on a mac? The build.xml in the natives section needs a bit of work I think. The ppc compatible gcc is now fully depricated in 10.8.

Yeh to build the mac natives the build.xml needs to run on a mac and it will compile the natives for PPC, 32bit and 64bit into one universal fat binary.  The current mac code is pretty old and targets OS X 10.3+ (includes various workarounds/hacks for problems in those old OS X's). A fresh rewrite should target OS X 10.5+ and only the 32bit and 64bit arch's. Support for PPC architecture and any OS X lower than 10.5 should be dropped now as the marketshare there is now insignificant and Cocoa wasn't as mature on those older OS's.

Also can this problem not be solved by using a similar strategy to the linux code? I've seen other opengl programs work just fine which are written in c/c++ rather than objective c

Would be great if we could get away with only using C but Cocoa is really the future on OS X and is now the only officially supported framework. Previously both Java and Carbon were also officially support hence why we've been able to get away for so long just using AWT on OS X.

[abcdef]

Just a quick update on things, haven't done too much in the last few days (Weather has been great where I am so been out enjoying it!)

I can now get everything to compile and build from the main ant script, I had to fiddle with the mac osx build script a bit.

Its looking like 10.6 should be the new min version supported because when carbon went there was one function in org_lwjgl_opengl_Display.m which needed changing and the new function is is only available to 10.6+

JNIEXPORT void JNICALL Java_org_lwjgl_opengl_MacOSXDisplay_nHideUI(JNIEnv *env, jobject this, jboolean hide) {
    if (hide == JNI_TRUE) {
        [NSApp setPresentationOptions:NSApplicationPresentationAutoHideDock];
    } else {
        [NSApp setPresentationOptions:NSApplicationPresentationDefault];
    }
}

SetSystemUIMode has not been removed and not available.

https://developer.apple.com/library/mac/#documentation/Carbon/reference/Dock_Manager/Reference/reference.html

So now it's all building going to start making some changes...from looking at the code it looks like org_lwjgl_opengl_MacOSXCanvasPeerInfo.m needs to changed

p.s. I noticed that there are quite a few deprecations on the build, especially around opencl. org_lwjgl_opengl_AWTSurfaceLock.c has functions that are also deprecated which isn't surprising.

[princec]

I should think targeting 10.6+ is fine - less than 4% of Macs on Steam are using 10.5.8 (the minimum version required for Steam).

Cas

[EmuMog]

abcdef, I hate to ask this, but I was contracted about two months ago to both update the Minecraft renderer as well as fix LWJGL on OSX + Java 1.7. For the past couple months I've been concentrating on the renderer itself, but I was literally going to be banging out the necessary NSView subclass to fix the OSX + Java 1.7 issue either tomorrow night or Thursday night.

I obviously can't stop you if you're hell-bent on fixing it, but it would be greatly appreciated on this end of the keyboard if you leave it to me.

moderator removed references to #lwjgl issue, to prevent further derailment of thread