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..
|