SWT support and Mac pains

Recently I changed up the way jMonkeyEngine handles embedding in a Canvas. Where previously it was tied hard and fast to an AWT canvas, it is now generic, using registered constructors to allow building other types of canvases. This has been pretty great, allowing us to break up some package dependencies and open things up for new and interesting ways of using jME.

Along with that change, I checked in an implementation for jME in an SWT canvas. Here's where I need to apologize to developers on newer Macs. SWT does not work well in a mixed environment that uses cocoa and even having the swt lib jar from eclipse in your classpath causes errors like this: (even if you are not touching SWT AT ALL, which I find a bit heavy handed.)

2008-07-19 18:14:48.689 java[7031:10b] [Java CocoaComponent compatibility mode]: Enabled
2008-07-19 18:14:48.690 java[7031:10b] [Java CocoaComponent compatibility mode]: Setting timeout for SWT to 0.100000
2008-07-19 18:14:49.633 java[7031:12503] *** -[NSConditionLock unlock]: lock ( '(null)') unlocked when not locked
2008-07-19 18:14:49.633 java[7031:12503] *** Break on _NSLockError() to debug.

If you are not using the properties dialog, jME will launch in the background but be unresponsive to input.

Obviously, this sucks when you are developing because your only other choice is to remove the jar and try to ignore over 100 compile errors. Ugh. So again, sorry.

The ideal situation would be to get a fixed swt jar, but it looks like that will have to wait for the cocoa implementation of swt (possibly part of the eclipse 3.5 release.) I tried to build my own from cvs, but the build script gave me errors about some of the eclipse custom ant tags (even though I have the pde build ant in my ant classpath) and jarring up the bin directory gave me a 2MB jar that still produced the above quoted error and symptoms.

So, in the end, I decided to just write an empty version of the classes and interfaces from swt that jME touches and check that in as a temporary lib for macs with a broken java carbon bridge (or if you are running 64bit only java 6.) At least that way you can compile and run jME (although obviously not the swt part) without errors. Hope that work makes up somewhat for your pain, Mac devs. Find the jar in the /lib/swt/macosx-cocoa/ direction.

You can download the source code for this empty implementation here if you really care to. It's all empty stuff except the SWT class which is copied partially from the real thing.


Kevin said...

There are 32 bit build Cocoa builds of Eclipse available already. There will be 64 bit builds available within the next week or two.
Building the SWT libraries should be pretty simple. On the JRE tab of the launch configuration you need to be sure that you are running in the same VM as Eclipse, and if you don't want to build Mozilla's XUL Runner, the easiest thing to do is comment it out in the make file.
If you need any help with SWT, send me an email and I'll be glad to give you a hand.

Kevin said...

should have left my email address :)
iamkevb at gmail dot com

Renanse said...

Thanks Kevin, i appreciate the advice. Will a 64 bit build solve the issues we are facing though?

Kevin said...

The 64 bit port will allow you to use Java 6, but won't solve the problems you have.
I just looked at jmonkeyengine.com. Until we have OpenGL support in SWT/Cocoa, the port isn't going to be any help to you.
Going from memory JOGL has some reference to AWT, and that's what's causing the errors you're seeing. Looks similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=221483.