macdevcenter.com
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Mixing Java and Titanium: Part Three

by James Duncan Davidson
09/25/2001

Editor's note: Recently James Duncan Davidson published a series of weblogs on the subject of Java and Mac OS X for O'Reilly Network. These blogs contained lots of useful information that was too good to get buried deep within the network labyrinth, so we've updated them and are now presenting the content in a series of three articles. This is part three of this three-part series.

Today Davidson takes a look at Cocoa, and Objective-C in particular, and discusses it from the point of view of a Java programmer. He also takes a brief detour from this topic to share his views on swing apps for Mac OS X.

Cocoa and Java: Lots of promise, but...

Currently, the Mac Devcenter is running a series of articles by Mike Beam titled Programming with Cocoa. This series is geared toward looking at Mac OS X's Cocoa APIs as expressed in Objective-C. This is only natural given that Objective-C is the native language of Cocoa, but since I am approaching this article from the perspective of a Java coder, I've been experimenting with Cocoa's Java APIs.

There is a lot of general documentation on Cocoa at Apple's Cocoa Developer web site. And the tutorial on how to use Cocoa in Java is a good start. It shows the power of Interface Builder and Cocoa, and yet is an easy read. I had the sample Temperature Converter up and running in no time. But, after that point, the remaining Java-oriented documentation consists mainly of the Application Kit and Foundation API references. And worse, these references are incomplete ports of the Objective-C documents. For example, the following sentence comes from the Java application references for the NSEvent class:

"NSWindow and NSApplication define the method nextEventMatchingMask:untilDate:inMode:dequeue:, which allows an object to retrieve events of specific types."

The above makes very little sense to a Java programmer unless they have some experience with Objective-C message-naming conventions. Somebody that had never seen Objective-C might translate the above to a Java-ish method of nextEventMatchingTask(untilDate, dequeue) and looking in the documentation for NSApplication, there is no exact method of this signature. Instead, there is a method signature of nextEventMatching(int mask, NSDate expiration, String mode, boolean flag). At this rate, I'd rather just have sparse Javadoc-generated documentation.

Don't get me wrong, after my initial foray into Cocoa, I'm impressed. Interface Builder is a dream to work with and the performance of Java driving the native Cocoa widget set is impressive. There is lots of promise here, but right now the documentation is not geared toward Java programmers. To make heads or tails of it, you end up learning quite a bit of the Objective-C language. There is nothing wrong with knowing another language, and I've found Objective-C to be fascinating. However, a lot of work remains to be done before typical Java programmers will be able to easily use the Cocoa APIs.

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

Because of Apple's weak Java-based Cocoa documentation, I have had to get somewhat familiar with Objective-C in order to explore Cocoa-Java programming. Even though they are both highly object-oriented languages, there are quite a few differences between the two.

The most obvious difference between the languages is one of syntax. One of the early strengths of Java was that it used a syntax for method declarations that was very similar to C functions. Objective-C, on the other hand, uses a syntax that is much closer to Smalltalk (the grandaddy of object-oriented languages). In an earlier installment of this series, I quoted the following example from the Apple NSEvent documentation:

"NSWindow and NSApplication define the method nextEventMatchingMask:untilDate:inMode:dequeue:, which allows an object to retrieve events of specific types."

A Java programmer not familiar with Objective-C or Smalltalk will look at that paragraph and scratch his head. If you don't know the syntax, it is hard to parse out what the method name is and what its parameters are. It helps tremendously to look at the actual method signature from deep down in the documentation (or in the header file) where we find out that the method really is:

- (NSEvent *)nextEventMatchingMask:(unsigned int)mask untilDate:(NSDate *)expirationDate inMode:(NSString *)mode dequeue:(BOOL)dequeue

This method signature, even though it is still sporting all the colons and has pointer stars, is quite a bit more meaningful to our Java programmer. It has parameter names and the types of objects or data that the parameters expect. And it is a lot easier to map its Java equivalent:

nextMatchingEvent(int mask, NSDate expiration, String mode, boolean flag);

Comment on this articleJames Davidson has touched on a number of differences for Java programmers as they look at Objective-C. Do you have any additional observations?
Post your comments

Previously in this series:

Mixing Java and Titanium: Part 1

Mixing Java and Titanium, Part Two

The lesson? Make sure to dig deeper into the documentation or even take a look at the actual header files so you can better map what Objective-C's methods are doing into your way of thinking. At least until you get used to the different syntax.

A less obvious, but larger difference between the languages is that Objective-C is actually much more dynamic at runtime than Java is. Most of the time in Java, you have to know the type of the object that you are working with in order to call methods on that object. For example, you have to know that you have a reference to an object of type java.awt.Component before you can call the show() method. In Objective-C, quite simply, you don't. You can simply call the show method. More accurately, you can send the show message to an object and if the object knows how to, it will show itself. This level of dynamic binding is one of the things that makes Cocoa UI Programming and Interface Builder work well.

To be sure, the same sort of effect can be had in Java using the Reflection APIs. Many of the programs that I have recently written in Java use Reflection heavily and perform the same kind of magic, but with much more code. Here's an example of asking a Java object to show itself:

try {
    Class objectClass = object.getClass();
    Method showMethod = objectClass.getMethod("show", null);
    showMethod.invoke(object, null);
} catch (NoSuchMethodException nsme) {
    // do something
} catch (IllegalAccessException iae) {
    // do something
} catch (InvocationTargetException ite) {
    // do something
}

So, what are the big shortcomings of Objective-C if you have a strong Java background? The number one issue that I have run into is memory management, or the lack of it compared to Java's garbage collection. Stepwise has published some nice rules for memory management in Cocoa, but it is still a pain. The second issue is the lack of package namespaces like com.oreilly.*. Packages, and the package-protected level of method visibility, have been a lifesaver in several of my Java projects. Naming conventions such as the NS prefix used in the Foundation and Application Kit libraries are not as good a solution.

Even so, Objective-C has turned out to be a lot more interesting than I initially thought it would be. I'll be spending quite a bit more time playing with Cocoa using both the native Objective-C bindings and the newer Java bindings. When I've formed up some more opinions, you can be sure I'll post them here.

Pages: 1, 2

Next Pagearrow