Re: Native Cocoa vs Java performance question
Re: Native Cocoa vs Java performance question
- Subject: Re: Native Cocoa vs Java performance question
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 15 Apr 2003 13:09:58 -0400
On Monday, Apr 14, 2003, at 15:21 US/Eastern, Jim Rankin wrote:
On Sunday, April 6, 2003, at 11:22 AM, Bill Bumgarner wrote:
I currently am implementing a pretty good sized project in Cocoa/Java
and it works just fine.
Out of curiosity, what set of requirements led you to choose
Cocoa/Java (assuming it's any of my business :), over say Cocoa/ObjC
or Swing?
In this particular case, the Client had an already existing
JINI/JavaSpaces based solution for which they wanted a Native OS X GUI.
That solution already provides a fairly rich set of client side Java
APIs that make talking with the server straightforward.
So, the options were:
- use Java/Swing and go for a pure Java solution.
- use Cocoa/Java
- use Cocoa/ObjC
- use Cocoa/Python via pyobjc.sourceforge.net
Java/Swing:
While Swing would certainly be a viable option, programming Swing
based UIs is considerably more effort to yield a less rich and less
"native" solution. While Apple has done a brilliant job of making
Swing based apps mostly "just work" under OS X, they still have
idiosyncrasies that annoy the heck out of a user that is used to the
"native OS X" application behaviors.
Also, Swing based apps on OS X simply do not perform well. I have
yet to use a Swing based app that doesn't lag a bit as the user
navigates the GUI. The release of 1.4.1 + Cocoa/Swing has definitely
helped, but apps like jEdit and some of the Java IDEs are still
relatively unusable on all but the fastest of machines.
Cocoa/ObjC
Since Objective-C is the language of implementation for Cocoa
itself, choosing Cocoa/ObjC eliminates all intra-language bridge
related issues. And there are a slew of issues. However, choosing
this particular route would have required either implementing some
other kind of client than the Java based JINI/JavaSpaces API provided
by the client or would have required still dealing with the ObjC/Java
bridge, but pushing it down to a below-the-UI level.
The ObjC/Java bridge generally works well when the classes were
designed for bridging, but it is very difficult to work with classes
that have not has some engineering effort expended on bridging.
Support for bridging new classes seems to have largely disappeared over
the last few releases of OS X/Dev Tools, etc... A look in
PrivateFrameworks reveals that a lot of thought and engineering has
been expended on the problem, but the resulting APIs have yet to be
made public (if they ever will be).
Cocoa/Java
Assuming the 'Cocoa in Java' part of Cocoa/Java works, then this
route allows me to fully leverage the client provided JavaSpaces/JINI
based APIs while also taking full advantage of the Cocoa APIs.
This route is not without its problems. In particular, there are
some memory management related issues that I have been unable to debug
properly. I have a workaround in place, but it is kind of disgusting.
Overall, the pain of dealing with the Cocoa APIs in Java is more
than compensated for by not having to re-invent the client's wheel in
ObjC or Python (or by pushing the bridging down to in between the Model
and Control layers).
Cocoa/Python
Via
http://pyobjc.sourceforge.net/, it is possible to build full
fledged, production quality, Cocoa applications written purely in
Python or in a mix of Python and Objective-C.
This particular choice would suffer from the same disadvantages as
Cocoa/ObjC, but would have the distinct added advantage of producing a
codebase in Python. In my experience, apps written in Python tend to
be fewer lines of code, are easier to maintain and overall developer
productivity is much greater.
With that said, I would not make the choice to go the Cocoa/Python
route without the complete support of my clients; i.e. they need to be
made fully aware of the details of that decision.
--
So, in the end, I chose Cocoa/Java because it seemed to be the fastest
way to a successful implementation. It requires the least amount of
"re-inventing the wheel" while still producing an application that
looks/feels like any other properly written OS X native application.
For the most part, I have not regretted the decision. There have only
been two issues that are a direct result of Cocoa/Java that have proven
to be particular nasty. There are a number of annoyances, but nothing
catastrophic.
- If you try to create a custom subclass of certain UI classes and use
those subclasses in IB, then you either have to implement an
undocumented constructor or-- in certain situations-- it simply can't
be done because the NIB will fail to unarchive. Specifically,
creating a subclass of NSButton (a draggable button, in my case)
requires the implementation of an undocumented, protected, constructor
-- without that constructor, the app goes *kerblooie* when the NIB is
loaded. It appears to be impossible to create a subclass of
NSTableColumn that can be mentioned and used directly in IB-- app
crashes as the NIB is loaded. Both situations were worked around with
some code...
- There are memory management issues that appear to be the result of
conflicts between retain/release and the Java garbage collector.
These are nasty -- literally, the problem will crop up intermittently
depending on how often and when the Java GC thread actually reaps
objects. I have had situations where the loading of a NIB would cause
a crash *as the nib loaded and before any of my code executed*. The
only way to "fix" this-- and I use the term "fix" loosely-- is to
create permanent references to the objects potentially causing the
crash on both sides of the bridge. The trick, then, is to figure out
how to make the reference permanent before the GC takes out the object
and, eventually, the app.
- IB can autogen Java class declarations just fine, but it can't parse
the code it generates. As such, you have to keep the actions/outlets
in sync between source and IB manually. An annoyance, nothing more.
--
For reference, the solution actually involves three applications that
work in tandem. The apps mostly just use the Cocoa widgets directly,
but there are a handful of places where I have had to do some fairly
funky custom widgetry to achieve the desired behavior. All in all, it
is around 4,700 lines of code and 30 different individual interfaces
(one of the apps is a System Preferences style control/configurator app
-- figuring out how to achieve toolbar/drag-n-drop behavior like SP was
entertaining....)
b.bum
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.