AddThis Social Bookmark Button

Listen Print Discuss
Mac OS X > Excerpts >

Mixing Java and Titanium: Part Three
Pages: 1, 2

Swing apps on Mac OS X: It's all good and getting better

The most frequent question people have for me when I tell them that I am developing Java on Mac OS X is, "How well do your applications run?" And the answer is that my experiences have been really good -- stunningly good in fact. But then, most of my applications have been faceless server applications and most of the cross-platform problems in Java hit GUI applications. As luck would have it, a few of my friends that develop GUI applications have started developing on Mac OS X, as well and I have good news to report.

Learning CocoaLearning Cocoa
By Apple Computer, Inc.
Table of Contents
Index
Sample Chapter
Full Description
Read Online -- Safari

One of these friends, Greg Murray, has been working on his own Java code editor for the past year or two in his spare time -- that is, when he is not working on the J2EE Blueprints at Sun. As he makes improvements, it is turning into quite a decent tool for hacking on Java code. You can find this program, called MightyJ, at http://www.mightyj.com/. Greg originally developed this application on Linux and Windows, but after seeing my OS-X-based laptop and its JDK 1.3 implementation, he took the plunge and bought a Cube and started hacking on MightyJ using OS X. And his experience was almost seamless. They only place he had to change code was in some custom components he built himself. A few days later, he was raving about how MightyJ looked just like a native OS X app and was impressed by the lack of problems when running it on OS X. Now, his biggest complaint is that he doesn't have a Mac OS X machine at work.



You can find screenshots of MightyJ running on OS X at http://www.mightyj.com/screen_shots.html.

Even better, it seems that Swing on OS X is just going to get better. Apple has been hard at work at figuring out how to get hardware acceleration behind Swing to drastically improve performance and has been showing this technology off at Apple's Worldwide Developers Conference (WWDC). In demos, it turned previous choppy resize operations into silky smooth ones. This technology will be shipping as part of the upcoming Java update, but will not be turned on by default as it is not quite ready for primetime. You can bet that I'm digging in to find more information about this technology and will get details out as soon as I can.

A bit more Objective-C from a Java point of view

Earlier, I discussed a few of the differences between Objective-C and Java. Now I'm going to take a look at a couple of things that are annoying, and sometimes painful, about working in Objective-C. Especially when coming from a Java background.

First, Objective-C is based on the strict ANSI C standard. This means that you are limited to declaring new variables to the top of a block of code. What happens in practice is that the following code (a snippet that all Java programmers have used a bazillion times and have automatically programmed into their fingertips) will not compile:

for (int i = 1; i < j; i++) {
    // do stuff
}

Instead, you need to write your code to look something like:

int index;
for (index = 1; index < j; index++) {
    // do stuff
}

This looks innocent enough in the example above, but most methods have a page or two (hopefully not more!) of implementation. In real life, the example looks more like the following:

int index;
// Lots of code in method...
[[NSColor whiteColor] set];
NSRectFill(rect);
for (index = 1; index < j; index++) {
    // do stuff
}

Declaring an index a page before the for loop that uses it is quite annoying. Or declaring any short-lived variable too far from where it is being used is a sure way to run into readability problems. At WWDC, it was mentioned that this problem will likely go away as the C support is upgraded. Until that happy day, there is a workaround. Simply open a new block of code with curly braces. Here's an example:

// previous code in method...
[[NSColor whiteColor] set];
NSRectFill(rect);
{
    int index;
    for (index = 1; index < j; index++) {
        // do stuff
    }
}

The second issue is one that is not picked up the by the compiler. It is the accidental case of using an `=` assignment operator in an if(condition){} statement instead of the `==` comparison operator. There have been at least three cases in the last few days where the following code caused non-obvious problems in my programs:

if (answer = NSAlertDefaultReturn) {
    sp = [NSSavePanel savePanel];
    [sp setRequiredFileType:@"expenses"];
    answer = [sp runModal];
    // ...
}

The above code will compile just fine, but trying to figure out what is happening at runtime can get a little tricky. Even if you have a hint of the problem, having to scan pages of code looking for a single missing '=' character can make your eyes cross.

Are these issues enough to keep me from further experimentation with Objective-C? Nope, not at all. But they do constantly annoy me as I explore the language and the Cocoa frameworks. They take a little bit of the shine off an otherwise enjoyable experience. Just enough to make me really appreciate some of the polish that the creators of Java put into the language and its semantics.

James Duncan Davidson is a freelance author, software developer, and consultant focusing on Mac OS X, Java, XML, and open source technologies. He currently resides in San Francisco, California.

Return to the Mac DevCenter.