Re: Cocoa Java vs Swing Java classes
Re: Cocoa Java vs Swing Java classes
- Subject: Re: Cocoa Java vs Swing Java classes
- From: David Findley <email@hidden>
- Date: Sun, 14 Oct 2001 09:06:31 -0500
On Sunday, October 14, 2001, at 12:47 AM, Alex Reynolds wrote:
Why should I use Cocoa Java for GUI elements when I can use Swing Java
to achieve the same graphical effect?
That is to say, what is the benefit of using Cocoa classes for Java
development? What Cocoa Java classes provide functionality not
available directly or indirectly with "regular" Java?
Two words: Development speed.
I'm having to write an application that will be run pretty much
primarily on Windows (for the UM-St. Louis Physics Department). I'm
porting an old C++ DOS based program that they are still using in the
astrophysics courses there. I really owe my old advisor a lot for
putting up with me as an undergrad, so I'm converting it for free. :)
Since I really want to write it on my PowerBook (where all my tools are)
I decided to write it in Java with Swing. I guess I had the same
question as you at that point: how hard could it possibly be? It looks
the same, doesn't it?
I found out soon enough: Cocoa = Swing + _lots_ and _lots_ of common
interface _behavior_ for free!
True, an application written with Swing looks a lot like a Cocoa
application (when run on the Mac), but with Swing you have to write a
_lot_ more code to get it to act the same. If you are interested in
seeing this in action, go to
http://findley.mine.nu/photom/ and download
the app that I'm converting. You'll need a couple of astronomy images
to actually use the app, you can get them from
http://www.sbig.com/. We
use their cameras at the observatory.
Anyway, you'll notice that there's no Cut, Copy or Paste, or Undo, or
Redo, or Save (yet). This is because Swing is an "appearance" layer,
not a "behavior" layer, and does not provide a foundation for those
items. There's no "appkit" in Swing. You really are on your own
there. The menus don't enable properly yet (for the most part). If you
close all the windows, you have to quit the program before you get it
back, because Java is really designed for the metaphor where a Menu Bar
belongs to a window, not an application. (Like X Windows and Windows.)
Therefore, each time you switch to a different window in my application,
it's actually a DIFFERENT menu bar at the top of the screen. When you
close all the windows, the only menu bar left is the "application" menu
bar, which only allows you to quit. There's a fair bit of work involved
in maintaining the fiction that a Swing Java app is a real Mac
application. And I'm not even close to being done.
Granted, Swing _does_ include functions for enabling and disabling menu
items, but then you have to build a WHOLE architecture on top of that to
make sure the calls get called at the right time. Cocoa provides this
right off the bat, saving literally days of work. Also, because Swing
lacks a good notification system between the application itself and the
UI elements (I think this is due to fact that Java is a more strongly
typed language than Objective C, especially when dealing with objects),
you have to create a lot of extra subclasses to do what a single
notification call could do in Cocoa.
I've easily spent over 200 hours on this project, and it's no
exaggeration to say that I would have been DONE by now, if I could have
used Cocoa and Objective C. And I would have had unlimited undo/redo,
cut, copy, paste, save, etc... I doubt I'm really going to spend the
time to add all the niceties that I'd expect from a Mac application.
But I don't have choice for this app, since it _has_ to run on Windows.
Oh, well. It really makes me appreciate Cocoa and Objective C all that
much more. :)
Good luck, whatever you choose (if you have a choice). But if you do
have a choice, Cocoa will give you a tremendous speed advantage, even if
you have to learn it from scratch!
My $.02.
David Findley