Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Re: Mac OS X Port by Carolyn MacLeod

Hi,

I suggest that we all post our resume, so that we can just all see who has the most Mac development experience. It probably won't me... :)
Me neither :-(

If we use the Java Cocoa binding for the OS X port, we have a three level binding: SWT widget -> Java Cocoa widget -> native Cocoa widget. From the SWT philosophy, this is one level to much.

As I see it, the SWT philosophy has three layers too.
1. A public SWT API every plugin developer can use (SWT widgets)
2. A wrapping layer for native calls
3. A platform specific UI API

The difference with Cocoa is that
1. Cocoa is an OO widget framework, in contrast to all those procedural frameworks. 2. Java Cocoa is a wrapping layer supplied by the UI API supplier. The source is not open, so you can´t be sure what exactly happens and most importantly you can´t fix bugs or increase performance easily. Still we have to condier it a choice, since its usage should decrease development time.


SWT to native Cocoa,
Java-Cocoa to native Cocoa
both are thin layers. If you use the three level approach, you make it a fatter binding.
You don´t loose much by calling Java Cocoa from SWT. You _just_ don´t control the code of the native mapping anymore. I see the problem with that, but I´d give it a try. Later on you still can change to JNI if the approach proves buggy/slow/too complex to handle/...


What we formally can measure is the memory usage difference. I think that the preference of going JNI/JDirect or JCocoa is a matter of personal preference. To comply to the SWT idea, I prefer the JNI or JDirect approach, also for similarity between the various ports.

I don´t think using Java Cocoa contradicts the SWT idea. In contrast adapting an OO framework like JCocoa to SWT would show the flexibility of the SWT concept. I agree with you, that a JNI/JDirect approach ensures similarity between various ports - but that can only be one of many more important reasons to use JNI/JDirect.
Think different. *g* (applies to my own position as well)

martin



Back to the top