Cocoa mail archive
Re: Java vs. Objective-C for Cocoa
FROM : Scott Ellsworth
DATE : Mon Apr 25 20:23:28 2005
Zacharias: I note that your original question got a bit drowned out
in our re-factoring discussion. Take the following for what you paid
for it.
On Apr 22, 2005, at 11:14 AM, Zacharias J. Beckman wrote:
> So, if anyone that has done both native and Java based OS/X
> development wants to send a few pointers and opinions my way I'd
> really love to hear them. Thanks!
I tend to end up with a fair amount of Java code in my projects, as
that is what we get paid for, and we have a lot of high quality,
tested library code lying about the shop written in Java. I thus
will often need to get at it from a Cocoa app, or need to get an OS-
specific feature using some ObjC from Java.
I have written Java code that called out to native libraries using
JNI, which also works to call various foundation and objc code. I
try not to throw much across the JNI barrier, but it did work just
fine to get access to the Accelerate framework and its altivec-
optimized BLAS. Accelerate just screams.
Runtime.exec and files on the filesystem can also work, for the
ultimate in seperation, but that has a fairly high overhead. This
worked well to call out to MATLAB, and then to replace MATLAB with
custom c++ code.
Going the other way, Cocoa-Java worked well as a way to call Java
library code in a primarily ObjC Cocoa application. My limited
experience tends to make me lean towards using ObjC for anything
that IB might have to know about. (I like the Java language and some
of the better libraries a great deal, but ObjC is still Cocoa's
native language. If nothing else, there is a lot more sample code,
better help, and more documentation in ObjC. That said, I get my
libraries written faster with a refactoring editor, and they are
available in more places for more clients with Java.)
A recent task involved an ObjC UI, written in IB and everything, that
had a button action using Java. It worked quite well, allowing me to
re-use a matrix inversion and calculation routine I wrote a few years
back without change. (To be precise: the button press spun off an
NSTask to compute about a hundred network flow models, which were
then poured into a Core Data data structure managed on the ObjC side
of the house. Worked great.)
If you go that route, start with a Cocoa-Java project, then do
everything in standard ObjC Cocoa until you reach the native model
part. I would not recommend this for filling out a zillion rows in
an NSTableView, but for a button proc to do a time consuming task, it
is not bad at all.
Note; you will suffer JVM startup time, but this was not a big deal.
I can send you a really simple sample project if you need it.
One note: projects that have to _compile_ Java, rather than just use
some classes from a jar, should start with the Cocoa-Java
stationary. If you do not, it creates a project type that does not
know how to compile Java. I really, really hope they fix this
someday, but using a Cocoa Java project as a starting point does work.
Scott
DATE : Mon Apr 25 20:23:28 2005
Zacharias: I note that your original question got a bit drowned out
in our re-factoring discussion. Take the following for what you paid
for it.
On Apr 22, 2005, at 11:14 AM, Zacharias J. Beckman wrote:
> So, if anyone that has done both native and Java based OS/X
> development wants to send a few pointers and opinions my way I'd
> really love to hear them. Thanks!
I tend to end up with a fair amount of Java code in my projects, as
that is what we get paid for, and we have a lot of high quality,
tested library code lying about the shop written in Java. I thus
will often need to get at it from a Cocoa app, or need to get an OS-
specific feature using some ObjC from Java.
I have written Java code that called out to native libraries using
JNI, which also works to call various foundation and objc code. I
try not to throw much across the JNI barrier, but it did work just
fine to get access to the Accelerate framework and its altivec-
optimized BLAS. Accelerate just screams.
Runtime.exec and files on the filesystem can also work, for the
ultimate in seperation, but that has a fairly high overhead. This
worked well to call out to MATLAB, and then to replace MATLAB with
custom c++ code.
Going the other way, Cocoa-Java worked well as a way to call Java
library code in a primarily ObjC Cocoa application. My limited
experience tends to make me lean towards using ObjC for anything
that IB might have to know about. (I like the Java language and some
of the better libraries a great deal, but ObjC is still Cocoa's
native language. If nothing else, there is a lot more sample code,
better help, and more documentation in ObjC. That said, I get my
libraries written faster with a refactoring editor, and they are
available in more places for more clients with Java.)
A recent task involved an ObjC UI, written in IB and everything, that
had a button action using Java. It worked quite well, allowing me to
re-use a matrix inversion and calculation routine I wrote a few years
back without change. (To be precise: the button press spun off an
NSTask to compute about a hundred network flow models, which were
then poured into a Core Data data structure managed on the ObjC side
of the house. Worked great.)
If you go that route, start with a Cocoa-Java project, then do
everything in standard ObjC Cocoa until you reach the native model
part. I would not recommend this for filling out a zillion rows in
an NSTableView, but for a button proc to do a time consuming task, it
is not bad at all.
Note; you will suffer JVM startup time, but this was not a big deal.
I can send you a really simple sample project if you need it.
One note: projects that have to _compile_ Java, rather than just use
some classes from a jar, should start with the Cocoa-Java
stationary. If you do not, it creates a project type that does not
know how to compile Java. I really, really hope they fix this
someday, but using a Cocoa Java project as a starting point does work.
Scott
