So what’s wrong with Mac OS X?
Published by admin on Thursday, November 26, 2009 - 04:45:36 - Filed under General, News, Development
Only one small thing: Java.
Right now there are no less than 7 bugs related to the use of the SWT/SWT_AWT Browser opened for the Mac OS X platform on the Eclipse bugzilla system.
These bugs affects the browser suite on the platform, and even if you develop on Windows or Linux, your client may be on Mac so you will be affected too! All this to say that if you have 5 minutes to spare, please vote for a quick fix of these bugs - just register on the eclipse.org site, and add your vote.(You will see the complete list with some explanations in the Browser Suite FAQ pdf, just look at the last chapter: What are the know issues/bugs?)
And yet the worst ones, those which made me doubt that there ever will be a Mac OS X version, are now all fixed!
First there is the problem with the architecture. For those, like me, coming from the old days of Apple, you know that once upon a time there was a very special system, Mac OS, which was revolutionary then but whose binaries where not easily portable… The ROM of the Mac hardware was making all the difference because a good part of the system was already there, and notably UI code.
I still have the first 5 volumes of “Inside Macintosh” - the programmer’s bible, which still today are very good UI guidelines. There was the fundation of almost every UI widgets you use everyday.
But this system changed radically with the advent of Mac OS X. Now the OS is basically a clever port of Unix BSD, but it has very little to do with the old ways and the old ROM. Still Apple managed to maintain some level of compatibility with their old binaries. This is mainly due to a graphic framework known as Carbon. But Carbon had some flaws and was getting a little bit old with the time, so Apple decided to deploy a new graphical toolkit, which is Cocoa. - There is also another toolkit which is Quartz, to help with the confusion, but this is another story - So up to Mac OS X Tiger (10.4.x) the graphical toolkit used by Java to interact with the system was still Carbon, while now starting with Leopard (10.5+) and now Snow Leopard (10.6+) - is there a poll somewhere for the next OS name? Puma? Couguar? What else? - the default toolkit used by Java is Cocoa.
Enter Eclipse SWT, which itself is a graphical toolkit for Java, with closer integration with the native side (we call it heavyweight), compared to Swing (which is lightweight, mostly, meaning pure java) and AWT (which uses native peers but is more low-level than SWT).
Now imagine the combination of all these toolkits: Carbon/Cocoa/Quartz for the native side - SWT/Swing/AWT for java. Add the fact that you can have 32 or 64-bit OS, and some based on PowerPC architecture while others are Intel-based, and you will get a faint picture of the mess into which I stumbled when I first tried to run the NativeSwing framework on Mac OS X…
And boy, did I have some spectacular freezes! Simply launching a java app seemed like a miracle in itself (when it was working). Sometimes, the first launch would be fine, but don’t you dare resizing that frame! Because you will get some jolly nice deadlocks where the UI is entering a lock state, each Thread waiting for another waiting for another waiting for the first one…
One of the main problem on Mac OS X is that in Java the 2 main toolkits are actually competing to get hold of the first Thread (thread0). AWT needs its main event loop to be run in this thread, and the Eclipse guys determined that SWT too needed the Display object (the main object on which every components is based - giving access to the underlying system) needs to be created in this thread too!
It seems that we are forced to build multi-thread systems using a single-threaded model, almost.
Anyway, this is the dark secret behind the -XstartOnFirstThread that you will find the installer has added into your servoy.properties “servoy.vmClientArgs” property. All the other OS will ignore this flag, but clients using Mac OS X will not be able to run the beans unless this flag is set, forcing the AWT to be created on thread0, and allowing us to instantiate the native process from that thread too!
Note that this little (overly-simplified) overview of the threading problem we had to resolve took us (Christopher more than me, I must say, since I didn’t have a clue of these subtleties when I started digging) a few weeks to understand (did we ever?) and work around.
But once the SWT_AWT.newShell() bug was fixed in SWT, we managed to make the DJNativeSwing app to work on Mac OS X, and that was a first step. I created a main() program which was calling the main() Servoy client class using reflection as a proof of concept and it was only a matter of finding a way to integrate all this into the Servoy client…
Next episode I will tell you about that as well as introducing another interesting challenge: how to make this thing work in Serclipse, when we are so remote from managing the infamous first Thread!
So keep an eye on this blog, for now, I leave you breathless on this cliffhanger ;-)
