L. Mihalkovic

Cocoa SWT

As I made the switch to a Mac, it quickly became a apparent that there was going to be trouble in my new paradise when word started to leak out that Apple was going to retire Carbon as part of its move to 64bits.

So back last summer I started playing around with Cocoa and quickly managed to play with simple shells. Through the process it became clear that it was not so much hard as it was a tedious task. At the time, I started building my own Cocoa port project, based on the source Cocoa code embedded within the Carbon port. I posted something in the SWT mailing-list where I reported my findings as well as asked a couple questions about the general philosophy a ‘proper’ Cocoa port should follow in order to be approved. Little did I know that this first first post was going to be the first of a series of increasingly frustrating interactions with the SWT team [more on that later].

At the time, one of the questions I was asking was wether or not to follow in the footstep of Apple and basically replicate the core of their Java Cocoa bridge that other people could later use to bind additional Cocoa libraries to Java. My own experimentation was around the idea of something somewhat dynamic, whereby reflection and caching would be used to compose NSObject descendants based on the object descriptors defined in Bridge Support (used by Camel Bones Ruby Cocoa). Starting from these descriptors, a significant portion (if not all) of the low level code would be generated, thereby greatly simplifying the code maintenance (apple is committed to maintaining Bridge Work). This is basically how Ruby Cocoa works: it is capable to dynamically load a new descriptor and make the matching object available. Looking at the current SWT Cocoa code, it looks like the code all manually written.