[
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
|
2) I suppose it will be hard to find someone who is an experienced
programmer to Cocoa, since it´s a rather new API
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... :)
- licensing issues: I´m not sure about this. Is Java-Cocoa published
under APSL or can you use it as you like?
Why a licensing issue? We won't be distributing the Java-Cocoa jar file,
since this is installed on every OS X machine. The Win32 port doesn't
have the native widget library (some Windows DLL) in its distribution
either...
- size of jar file: the size of the directories in my system are (there
are no jar files):
i. application: 708 KB
ii. foundation: 424 KB
That´s not too much I suppose.
Same thing as above. These classes are on every OS X machine, so this
can't be an argument in any way to the Eclipse PMC.
- discard unused API: since cocoa is part of the system it´s not
possible to discard anything.
The problem with the Java binding, is that one doesn't know what other
Java objects are instantiated when you instantiate a Java Cocoa widget.
This could lead to unwanted side effects.
- direct mapping to the OS: don´t know how direct the mapping is.
That's why I prefer a direct JNI or JDirect binding to Cocoa. See one of
my other replies on this mather.
- OS versions supported: Mac OS X v. 10.1 and higher for sure, maybe v.
10.0 too
I would set the minimum version to be 10.1. Actually, 10.0 should have
been what 10.1 is now.
Regarding the articles to mentioned:
- one-to-one mapping:
As is stated in the document: "Java is a powerful high level
language [...]. Why use C?"
Everything said about the benefits of one-to-one mapping applies to
Java-Cocoa as well as any platform using C-natives.
The Java-Cocoa wrapper leverages us from using JNI. We can use the
Java-Cocoa in the implementation of the public API of the SWT classes.
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.
- thin layer between the application and the OS:
"efficient" - I can`t think of a thinner layer on top of the OS than
Java-Cocoa
"portable" - In Java-Cocoa there´s nothing interesting in the
C-natives since they don´t exist. The classes supplied by the
Cocoa-framework show the way directly into the heart of the OS.
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.
As for performance issues:
I´d suggest to write a test suite for Java-Cocoa and the same for
ObjectiveC-Cocoa and finally compare the results. This seems the only
way to get some reliable performance comparison. This hopefully helps
to find the path to go for the port.
What elements should such a test suite consist of? Any suggestions?
How can one measure the performance of ui-elements?
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.
Ringo
--
NOTE: My email address has changed!!
Bigfoot is changing their service offering. The free service is limited
to 25 emails a day which is too low for me. I will stop using Bigfoot
which means that both my BigFoot email addresses will become
invalid after 15 September 2001. Here are the new email adresses:
HOME: ridesmet@xxxxxxxxxxxxxxxxxxxxx
WORK: Ringo.DeSmet@xxxxxxxxxxxxxx
