Objective-C 2.0, Java and Annotations

Javaduke

Bye bye Java!

The Cocoa playground is closed for Java developers. New frameworks like Core Data are not available through the Java bridge. Java simply is to static, old-fashioned in comparison to (the even older) Objective-C language. But if you do not like C/Smalltalk syntax you can use dynamic script languages like Python with Pyobjc or Ruby with RubyCocoa. And of course AppleScript can be used to do programs, too.

But as C# is the primary development language for .Net, Objective-C is and will be the primary development language for Mac OS X/Cocoa. Therefore tools work best with Objective-C, documentation is best for Objective-C and there are a ton of examples and code snippets for Objective-C.

With Leopard Objective-C 2.0 will be introduced. It gets features to make it more attractive and easier for developers who are new on the platform (and if the rising number of WWDC attendees can be taken as a sign there will be more and more Mac developers the next years). Andy Matuschak did a nice reverse engineering of GCC sample code in order to avoid violating a NDA when writing about Objective-C 2.0 features.

With the new features, Objective-C catches up to Java:

  • Garbage Collector: even when memory management in Cocoa is not that difficult
  • for-each loop
  • Declaring methods of a protocol (=interface in Java jargon) as optional or required are a pretty nice extension. With this the compiler can check if the right methods of a data-sources or delegate are implemented. Java is to static for such a feature.
  • Support for declaring properties make life a lot easier and match the already prominent usage of KVC paths (person.address.city). I don’t understand why Java is still missing something similar.

Two big Java 5 features are missing:

  1. Generics: Objective-C has no direct support for generics (and I’m happy about that). But as C++ can be used in combination with Objective-C you can use C++ templates in your project (but without garbage collection in this part).
  2. Annotations: Annotations are structured metadata that you write in your source. Annotations are interpreted during compile or runtime to generate code or configure objects. Let’s take a closer look at that.

Annotations

In the early days of JEE (when we had to say J2EE) tools like XDoclet made life easier. J2EE used that hype technology called XML to describe your code. A (now) crazy idea and in the meantime and after some EJB specifications they repaired that. JEE 5 uses this new code description, metadata mechanism called annotations.

The following example would define a Webservice. The whole magic lies behind @WebService and @WebMethod which triggers generation of necessary network and data serialization code.

@WebService
public class HelloServiceBean {

   @WebMethod(name="helloworld")
   public String sayHello(String name) {
      return "Hello "+ name + " from HelloServiceBean";
   }
}

Annotations can make life a lot easier. And it would bring some benefits to Cocoa development too.

Every application on Mac OS X shall be scriptable. This makes it possible to integrate the application in automation processes and to combine different applications in order to fulfill a requirement (in ways the developers would not have thought about). It’s SOA for the desktop and it is great.

To make a Cocoa application scriptable you should design business clases which are independent of UI code and you have to write a XML file.

E.g. a business class for Person (old property style):

@interface Person : NSObject {
    NSString* firstName;
    NSString* lastName;
}
- (void) setFirstName: (NSString*) value;
- (NSString*) firstName;

- (void) setLastName: (NSString*) value;
- (NSString*) lastName;

@end

has a corresponding XML file to describe the scripting interface for it

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dictionary SYSTEM "file://localhost/System/Library/DTDs/sdef.dtd">
<dictionary title="Dictionary">
    <suite name="Suite">
        <class name="Person" code="cPER" description="a natural person">
            <cocoa class="Person"/>
            <property name="first name" code="pFNA"
                        description="first name of the person" type="text">
                <cocoa key="firstName"/>
            </property>
            <property name="last name" code="pLNA" 
                         description="last name of the person" type="text">
                <cocoa key="lastName"/>
            </property>
        </class>
    </suite>
</dictionary>

That looks a lot like those old J2EE deployment descriptor. This is just a simple example and things are much more complex in the real world. The script definition of Sofa Control is already around 200 lines long. Finding code-description mismatches can sometimes be a tough job and it would be nearly impossible without the great Sdef Editor.

There are for sure other parts which could benefit from annotations as well. E.g defining classes and properties for .Mac Syncing or dependent keys in Core Data classes.

This would be a big enhancements for the language. Perhaps someone already thinks about the feature set of Objective-C 3.0. In the meantime tools help to make life easier. Perhaps someone even comes up with some kind of XDoclet for Objective-C.

Besides annotations Objective-C seems to be on par with Java. So if you are a Java developer and if you want to feel the elegance of a dynamic language that is static when you want it to be static than start playing with Objective-C (2.0). It’s worth the time even if you never will develop an application with it.

One Response to “Objective-C 2.0, Java and Annotations”

  1. David Says:

    Thank you for sharing your experience, knowledge, and code with us.

    Standing on the shoulders of Giants, we can reach our target dates.