A Bit of Objective-C From a Java Point of View

by James Duncan Davidson

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 my last weblog, 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 is the method name and what are the parameters. 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 it it's Java equivalent:

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

The lesson for our Java programmer? Make sure to dig deeper into the documentation or even take a look at the actual header files so that he can better map what Objective-C's methods are doing into his way of thinking. At least until he gets 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 is 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.