Re: [platform-swt-dev] Mac OS X port - status? + Carbon vs Cocoa redux

[Mike Wilson <mcq@xxxxxxxxxxxxx>]

I've been talking to Andre Weinand about the possibility of doing a Carbon version. I'm hoping he'll have something to talk about here in the next few days. In the meantime, he indicated that he had tried using JDirect, but there were significant problems w.r.t. the event loop, so he has been looking at using real JNI. He has done enough experimenting to show that a standard SWT style "OS" class using JNI is faster than one built with JDirect. This alone would be enough of a reason to use JNI, even if there were no other problems.

McQ.

On Monday, January 14, 2002, at 06:03 PM, Mark Allerton wrote:

> Hi,
>  
> I've just joined the list, and have followed the thread about Maurice Parker's "blackmoon" work. Given that the last post was about a month ago I thought it was worth checking in for an update on how things were going.
>  
> I took a look at Maurice's project, and got it building fairly quickly (using IDEA and Project Builder) and was able to repro the Notification Center problem. It looked to me like a clash between Java GC and Cocoa reference counting - like the "ObjC end" of the NSSelector had been accidentally cleaned up. This is a problem that Apple talks about a little in the docs (for instance, see the last para of http://developer.apple.com/techpubs/macosx/Cocoa/JavaTutorial/simpleapp/Implementin_oller_Class.html.) If no progress has been made then I'm prepared to spend some time trying to debug this.
>  
> Maurice also mentioned trying to get a Carbon version up and running - and I'd be interested to hear of any progress on this.
>  
> While initially I leaned a long way towards Cocoa, and I completely agree with the reasoning that Java-Cocoa is basically the OS class "done for you", it's possible that Cocoa's semi-automatic memory management policies could be a poor fit with SWTs "manual" policy for OS resources. The JavaBridge may complicate this, but the problem could remain even when using a JNI --> ObjC --> Cocoa route (I also agree that such a route would inevitably break the "no smarts in the native code" pattern.)
>  
> The one big reason for using Cocoa over Carbon that many people have given is that you "get all the nice fonts" - but I think this is actually a misunderstanding of the differences between the two. In fact it's perfectly possible to write Carbon apps that use the Quartz 2D APIs instead of QuickDraw - it's just that you don't get them by default. I've yet to look into this in as much detail as I'd like, but it seems like it's possible to write a Carbon app every bit as good looking as a Cocoa one (I believe that the Finder is written using Carbon, for example.)
>  
> It should be possible to write a Carbon version without any "manual" JNI code using JDirect - but bugs in JDirect would be far less complicated to work around than bugs in JavaCocoa (where working around any single problem leads inexorably to writing a completely new bridge.)
>  
> I think that's quite enough for a first post. I'd be absolutely delighted to be proven wrong about the feasibility of using Cocoa, BTW - I have 3 years of Mac Toolbox programming under my belt from back in the early 90's, but I'm not all that nostalgic about it :-)
>  
> ..Mark..