Error while running TestSimpleGame

Troubleshooting General Help
1

Hello monkeys,



I'm trying to run the TestSimpleGame example available in jME 2.0 but I'm facing a problem I can't solve.



Here are the output availaible on the console :


29 sept. 2008 22:38:23 com.jme.app.BaseGame start
INFO: Application started.
29 sept. 2008 22:38:23 com.jme.system.PropertiesGameSettings <init>
INFO: PropertiesGameSettings created
29 sept. 2008 22:38:23 com.jme.system.PropertiesGameSettings load
ATTENTION: Could not load properties. Creating a new one.
2008-09-29 22:38:26.315 java[608:10b] [Java CocoaComponent compatibility mode]: Enabled
2008-09-29 22:38:26.399 java[608:10b] [Java CocoaComponent compatibility mode]: Setting timeout for SWT to 0.100000
2008-09-29 22:38:30.363 java[608:14103] *** -[NSConditionLock unlock]: lock (<NSConditionLock: 0x122d01960> '(null)') unlocked when not locked
2008-09-29 22:38:30.364 java[608:14103] *** Break on _NSLockError() to debug.
2008-09-29 22:38:30.526 java[608:14103] *** -[NSConditionLock unlock]: lock (<NSConditionLock: 0x100146df0> '(null)') unlocked when not locked
2008-09-29 22:38:30.527 java[608:14103] *** Break on _NSLockError() to debug.
2008-09-29 22:38:30.629 java[608:14103] *** -[NSConditionLock unlock]: lock (<NSConditionLock: 0x10010e320> '(null)') unlocked when not locked
2008-09-29 22:38:30.630 java[608:14103] *** Break on _NSLockError() to debug.
2008-09-29 22:38:30.788 java[608:14103] *** -[NSConditionLock unlock]: lock (<NSConditionLock: 0x122d032b0> '(null)') unlocked when not locked
2008-09-29 22:38:30.789 java[608:14103] *** Break on _NSLockError() to debug.
2008-09-29 22:38:30.891 java[608:14103] *** -[NSConditionLock unlock]: lock (<NSConditionLock: 0x122d03460> '(null)') unlocked when not locked
2008-09-29 22:38:30.892 java[608:14103] *** Break on _NSLockError() to debug.
2008-09-29 22:38:31.002 java[608:14103] *** -[NSConditionLock unlock]: lock (<NSConditionLock: 0x122d03750> '(null)') unlocked when not locked
2008-09-29 22:38:31.003 java[608:14103] *** Break on _NSLockError() to debug.
2008-09-29 22:38:31.105 java[608:14103] *** -[NSConditionLock unlock]: lock (<NSConditionLock: 0x122d03b20> '(null)') unlocked when not locked
2008-09-29 22:38:31.106 java[608:14103] *** Break on _NSLockError() to debug.
2008-09-29 22:38:31.208 java[608:14103] *** -[NSConditionLock unlock]: lock (<NSConditionLock: 0x122d03d00> '(null)') unlocked when not locked
2008-09-29 22:38:31.210 java[608:14103] *** Break on _NSLockError() to debug.
2008-09-29 22:38:31.316 java[608:14103] *** -[NSConditionLock unlock]: lock (<NSConditionLock: 0x122d04040> '(null)') unlocked when not locked
2008-09-29 22:38:31.317 java[608:14103] *** Break on _NSLockError() to debug.
2008-09-29 22:38:31.421 java[608:14103] *** -[NSConditionLock unlock]: lock (<NSConditionLock: 0x122d04240> '(null)') unlocked when not locked
2008-09-29 22:38:31.423 java[608:14103] *** Break on _NSLockError() to debug.



And here is my configuration :

- MacOS X 10.5.5 + Eclipse Ganymede + JDK 1.6
- jME 2.0 (freshly download from the svn, btw just before running the sample)

I toke care of installing the native libraries for OS X, and I don't really know what to do else. Have you been ever faced this kind of problem ?

Many thanks for your help and your time.
2
It is a known problem atm... SWT will cause issues on some macs.  If you are on a newer mac (I believe any running 10.5.X), the SWT-carbon stuff will not run and even having it in your jme classpath can break non-swt jme stuff you are trying to run.

It's crazy that this happens even when nothing is referencing swt... Sad  For now, I suggest leaving swt.jar out of your classpath if you get the above issue and ignore the compile errors in com.jmex.swt.  I know that is not ideal...  Other projects integrating with SWT have the same problem (Xith for example).  Fortunately, folks at eclipse and elsewhere are working on a Cocoa version that will be both 32 and 64bit compliant.

EDIT: Having the mac carbon jar in there was causing mac devs pain as mentioned above.  Sorry!  I've made empty versions of all the classes, interfaces and methods that we currently touch in swt and jarred that up into a swt_fake.jar file you can now find in /lib/swt/macosx-cocoa.  The old carbon swt is now in macosx-carbon for those on older macs.  Let me know if there are any further issues.  I will post the source for the empty swt implementation on my blog if anyone needs it.


Check out this thread for details

3

Thank you very much, for the link, removing the SWT jars had solved the problem.