For Intel mac users only at the moment, that is why I can't try this out myself. 
http://landonf.bikemonkey.org/static/soylatte/
Looks promising… 
missing native Swing implementation or sound does not matter that much in jME.
I would give it a try soon or later.
What I don't like is no support for Aqua. Everything, of course, runs under X11 and I don't know the real state of integration of X11 with OS X.
X11 implementations are known to be not an example of ligthweight GUI server. I hope that X11 running with Aqua would not use too many system resources. Till now I have only tryed it with normal Desktop applications (GIMP, Inkscape, Open Office, …) but I am afraid that a full 3D game could give it some real problems.
Saw it, but a little weary to install it, since my day job is Java on this Mac. Still waiting patiently for Apple to get their act together.
so does anyone know when apple are going to get the finger out and give us java 6???
any word in the ether??
Honestly, I don't think they'll ever finger out…
If you register as a developer in the ADC, you will discover that there is a beta release of Java 6 available to developers.
Ah, ah, ah! It's a joke! SoyLatte
Building
Due to bugs in 10.4's compiler, building the sources currently requires a Mac OS X 10.5 machine.
We need to be able to compile it under Tiger. Leopard, soon or later will have its Java 6!
Ender said:
I would give it a try soon or later.
What I don't like is no support for Aqua. Everything, of course, runs under X11 and I don't know the real state of integration of X11 with OS X.
X11 implementations are known to be not an example of ligthweight GUI server. I hope that X11 running with Aqua would not use too many system resources. Till now I have only tryed it with normal Desktop applications (GIMP, Inkscape, Open Office, ...) but I am afraid that a full 3D game could give it some real problems.
jME doesn't (have to) run under X11, does it? Only if you use Swing/AWT elements..
llama said:
jME doesn't (have to) run under X11, does it? Only if you use Swing/AWT elements..
You are right. LWJGL should make low level OpenGL calls that in Mac OS X should mean calls to CGL that is at a lower level than the Windows Server. Though, it should be investigated how the system decides wich Windows Server to use to open CGL windows, to be sure of that.
Anyway I was making a more general consideration. And it seems that they plan to develop the Aqua support.
The worst thing is the problem with OS X 10.4. At this point of the maturity of the project it would be advisable to give the possibility to everyone to compile it by his self. Instead we need to relay on Leopard. But as I said it is more probable that Apple will release a stable Java 6 for Leopard, while leaving abbandoned Tiger (as they did for Java 5 in Panther). So, Soylatte will be more useful for Tiger than for Leopard.
It seems that LWJGL is incompatible with Soylatte.
I should change its source and recompile it to make it work. I will make it. Stay tuned for news. 
$ java -cp .:res:jar/lwjgl.jar:jar/lwjgl_test.jar:jar/lwjgl_util.jar:jar/lwjgl_fmod3.jar:jar/lwjgl_devil.jar:jar/jinput.jar -Djava.library.path=native/macosx org.lwjgl.test.WindowCreationTest
The following keys are available:
ESCAPE: Exit test
ARROW Keys: Move window when in non-fullscreen mode
L: List selectable display modes
0-8: Selection of display modes
F: Toggle fullscreen
SHIFT-F: Toggle fullscreen with Display.destroy()/create() cycle
Exception in thread "main" java.lang.LinkageError: Unknown platform: Darwin
at org.lwjgl.LWJGLUtil.getPlatform(LWJGLUtil.java:291)
at org.lwjgl.Sys.createImplementation(Sys.java:111)
at org.lwjgl.Sys.<clinit>(Sys.java:100)
at org.lwjgl.opengl.Display.<clinit>(Display.java:111)
at org.lwjgl.test.WindowCreationTest.initialize(WindowCreationTest.java:80)
at org.lwjgl.test.WindowCreationTest.main(WindowCreationTest.java:284)
I am also giving a quick glance to the OpenJDK project. It is amazing how its web site is confused and bad organized. I was looking there because the non AWT/SWING code of JavaVM should be almost the same for every architecture/OS. Unfortunately the whole project is still quite complex and hard to understand.
Luckly I have a lwjgl source available under my Eclipse workspace projects, already configured for building.
I made the modification and I discovered that, even if LWJGL is OpenGL, the Windows Server is decided by the JavaVM. The Exception stack is probably caused by the absence of any X11 running on my Mac OS at the moment I launched the test. Probably I should launch manually X11 and use X11 Terminal to launch the LWJGL test.
$ java -cp .:res:libs/lwjgl.jar:libs/lwjgl_test.jar:libs/lwjgl_util.jar:libs/lwjgl_fmod3.jar:libs/lwjgl_devil.jar:libs/jinput.jar -Dava.library.path=libs/macosx org.lwjgl.test.WindowCreationTestreationTest
The following keys are available:
ESCAPE: Exit test
ARROW Keys: Move window when in non-fullscreen mode
L: List selectable display modes
0-8: Selection of display modes
F: Toggle fullscreen
SHIFT-F: Toggle fullscreen with Display.destroy()/create() cycle
Exception in thread "main" java.lang.InternalError: Can't connect to X11 window server using ':0' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.access$100(X11GraphicsEnvironment.java:52)
at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:155)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:131)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:68)
at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:89)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at java.awt.Toolkit$2.run(Toolkit.java:836)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:828)
at org.lwjgl.MacOSXSysImplementation.<clinit>(MacOSXSysImplementation.java:48)
at org.lwjgl.Sys.createImplementation(Sys.java:117)
at org.lwjgl.Sys.<clinit>(Sys.java:100)
at org.lwjgl.opengl.Display.<clinit>(Display.java:111)
at org.lwjgl.test.WindowCreationTest.initialize(WindowCreationTest.java:80)
at org.lwjgl.test.WindowCreationTest.main(WindowCreationTest.java:284)
EDIT: NEWS!
Launching from X11 Terminal resulted in this output. I saw a window appearing really quickly (just a instant) and immediately closing.
Obviously there is something that brokes when tring to get a display mode.
$ java -cp .:res:libs/lwjgl.jar:libs/lwjgl_test.jar:libs/lwjgl_util.jar:libs/lwjgl_util_applet.jar:libs/lwjgl_devil.jar:libs/lwjgl_fmod3.jar -Djava.library.path=libs/macosx org.lwjgl.test.WindowCreationTest
The following keys are available:
ESCAPE: Exit test
ARROW Keys: Move window when in non-fullscreen mode
L: List selectable display modes
0-8: Selection of display modes
F: Toggle fullscreen
SHIFT-F: Toggle fullscreen with Display.destroy()/create() cycle
Found 0 display modes
Problem retrieving mode with 640x480x16@-1
Problem retrieving mode with 640x480x24@-1
Problem retrieving mode with 640x480x32@-1
Problem retrieving mode with 800x600x16@-1
Problem retrieving mode with 800x600x24@-1
Problem retrieving mode with 800x600x32@-1
Problem retrieving mode with 1024x768x16@-1
Problem retrieving mode with 1024x768x24@-1
Problem retrieving mode with 1024x768x32@-1
java.lang.Exception: Failed to set display mode.
at org.lwjgl.util.Display.setDisplayMode(Display.java:243)
at org.lwjgl.test.WindowCreationTest.setDefaultDisplayMode(WindowCreationTest.java:299)
at org.lwjgl.test.WindowCreationTest.initialize(WindowCreationTest.java:87)
at org.lwjgl.test.WindowCreationTest.main(WindowCreationTest.java:284)
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$1(AWTSurfaceLock.java:99)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:89)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:86)
at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:64)
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:53)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:57)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
at org.lwjgl.opengl.MacOSXContextImplementation.create(MacOSXContextImplementation.java:46)
at org.lwjgl.opengl.Context.<init>(Context.java:113)
at org.lwjgl.opengl.Display.create(Display.java:759)
at org.lwjgl.opengl.Display.create(Display.java:709)
at org.lwjgl.opengl.Display.create(Display.java:691)
at org.lwjgl.test.WindowCreationTest.initialize(WindowCreationTest.java:92)
at org.lwjgl.test.WindowCreationTest.main(WindowCreationTest.java:284)
What a pity!
It's not that the windowing server is decided by the VM, clearly in the stacktrace you can see LWJGL is trying to use AWT for some purpose.
Did you look inside org.lwjgl.MacOSXSysImplementation? What does it use the Toolkit for? Display sizes or something? Maybe you can just replace that code.
You are right. Though it seems that LWJGL initialize AWT either on Mac OS and Linux.
Infact there is similar calls either in MacOSXSysImplementation and LinuxSysImplementation.
MacOSXSysImplementation.java (line 42):
static {
// Make sure AWT is properly initialized. This avoids hangs on Mac OS X 10.3
Toolkit.getDefaultToolkit();
}
LinuxSysImplementation.java (line 42):
static {
java.awt.Toolkit.getDefaultToolkit(); // This will make sure libjawt.so is loaded
}
The only one who doesn't seem to initialize AWT is Windows version, in fact, WindowsSysImplementation.java (line 42):
static {
Sys.initialize();
}
The reason is probably that the getAvailableDisplayModes() method is a native method in Windows implementation, WindowsDisplay.java (line 374):
public native DisplayMode[] getAvailableDisplayModes() throws LWJGLException;
While for Mac OS X implementation it is dependent on AWT and is pure Java method, MacOSXDisplay.java (line 168):
public DisplayMode[] getAvailableDisplayModes() throws LWJGLException {
java.awt.DisplayMode[] awt_modes = MacOSXFrame.getDevice().getDisplayModes();
List modes = new ArrayList();
for (int i = 0; i < awt_modes.length; i++)
if (awt_modes[i].getBitDepth() >= 16)
modes.add(createLWJGLDisplayMode(awt_modes[i]));
DisplayMode[] mode_list = new DisplayMode[modes.size()];
modes.toArray(mode_list);
return mode_list;
}
And in Linux it is something mixed, LinuxDisplay.java (line 656):
public DisplayMode[] getAvailableDisplayModes() throws LWJGLException {
lockAWT();
try {
incDisplay();
try {
DisplayMode[] modes = nGetAvailableDisplayModes(getDisplay(), getDefaultScreen(), current_displaymode_extension);
return modes;
} finally {
decDisplay();
}
} finally {
unlockAWT();
}
}
private static native DisplayMode[] nGetAvailableDisplayModes(long display, int screen, int extension) throws LWJGLException;
So hack that I'd say… 8)
Just make it return some display modes that work for you… (to try it out). In the worst case it can return an incredibly large list of well known modes (in the best case someone writes the native code for Mac).
The point is that Mac OS X implementation seems to be based on The AWT Native Interface that is a way to draw on AWT components using native code (and probably this is the reason for the jMEDesktop is so faulty, it is probably like a 2nd thread tring to draw on the same AWT component and controlling AWT events, this lead to conflictual behavior). There was an old so called Cocoa Java, basically a Java Extension to access directly Cocoa windows and components. But it is considered deprecated.
The alternative would be to implement my JNI access code to Quartz or other low level API, implement my custom LWJGL DisplaySystem, but my knowledge currently stops here. I have to read some documentation and tutorial before I can be able to do it.
And LWJGL actually uses that??? That would mean in OSX our LWJGL windows is actually an AWT window… Are you sure this isn't that just for the heavyweight AWT component that's used in Applets?
I don't get why it would use that for a simple OpenGL window or fullscreen OpenGL. Isn't the platform specific part of the OpenGL driver supposed to provide this?
Well, good luck 
Actualy I wonder how Mac OS X implementation is working.
In the Windows implementation all org_lwjgl_opengl_Display.c methods are defined in org_lwjgl_opengl_WindowsDisplay.h, that is included in org_lwjgl_opengl_Display.c.
The corresponding Mac OS X implementation, org_lwjgl_opengl_Display.m, does not includes the corresponding header, org_lwjgl_opengl_MacOSXDisplay.h, that (amazing!) is not included in any Mac OS X native source code of LWJGL.
Now, the possibilities are few, I have not understood anything (less than what I expected, then) of C and Objective-C, and there are magic situations in which there is no need for including headers, or there is actualy something wrong.
I guess they started on org_lwjgl_opengl_MacOSXDisplay.h but never finished?
But, rather than listen to me guess, there's a place were they can help you a lot more I think, the LWJGL forums… they're almost as friendly as us monkeys over there
I post an excerpt of my conversation with elias_naur the author of Mac OS X implementation. I think it can be useful to understand a lot of things about Mac OS X known problems.
And it appears that I got it, Mac OS X implementation is based on AWT.
[14:57] ender: ok thanks: 1) is Mac OS X, LWJGL window creation is based on JAWT?
[14:57] elias_naur: yes
[14:58] elias_naur: unfortunately, jawt was the only way I could get it to work reliably
[14:58] elias_naur: java and native cocoa/carbon didn't work well
[...]
[14:59] ender: ok thanks: 2) org_lwjgl_opengl_MacOSXDisplay.h is not included in org_lwjgl_opengl_Display.m as like is the windows counter part... why?
[15:00] ender: i am looking at the 1.1.3 source in this moment, though
[15:01] elias_naur: generally the auto-generated java headers are not that important
[15:01] elias_naur: you only really need them if you want a java defined constant (final static int blah = 2;) from native code
[15:03] ender: but in C, isn't needed to #include headers?
[15:04] ender: i am sorry but this part to me is still obscure... can be both definition and declaration in the same code?
[15:05] elias_naur: yes
[15:06] elias_naur: only reason you have the (redundant) definition in a header is for others to use the function without the implementation
[15:06] elias_naur: a bit like interfaces in java
[15:06] ender: I ask the last question: can I post your answers to jME forum to show that i guessed some things right?
[15:06] CIA-5: elias_naur * r2963 /trunk/LWJGL/src/native/macosx/org_lwjgl_opengl_Display.m: Mac OS X: Added missing #import
[15:06] ender: and to make jME users and developer aware of it?
[15:07] elias_naur: sure
[15:07] ender: ok thanks
[15:07] elias_naur: this channel is public and logged anyway
[15:08] ender: thanks