XCode is Apple’s professional grade development environment for MacOS X. It comes free with every version of MacOS X. That’s right. You don’t need to pay for it, and it’s the software that Apple recommends its developers use when writing software for that platform.

The first version of XCode was slightly buggy unfortunately. Additionally, whilst support for C and C++ was good, Java was less well supported. Code completion for Java was non-existent. When I develop Java programs, code completion is essential, unless you’re a fan of trawling through reams of physical or on-line documents. Competitor products, like Borland’s JBuilder have had code completion for years.

The new version of MacOS X (named Tiger) will be launched in the first half of 2005. It includes XCode 2, which at last will include Java code completion. So, given that it’s free, why not use this for developing Mac-centric Java software?

Well, there are still two things wrong with it:

1. You still can’t split editing views. This means that one window holds one contiguous chunk of code, so to get to see what’s at the top of a file when you’re near the bottom, you need to either open another window, or rely on intuition, code completion or the pop-downs at the top of the editing window to get to what you want. Split editing is essential for me, and it’s a feature I use a lot in JEdit. As an aside, I use JEdit for writing PHP projects, even though JEdit is really only designed for Java – it’s that good.
2. There’s no user interface builder for Java. The MacOS X software development kit — of which XCode is a part, and which is also free and comes with MacOS X — provides a User Interface Builder that constructs nib files for use with C++ programs. Basically, it describes the architecture of a user interface, which is then built into your XCode project. Nice and easy. Except nib files are not for Java.

The issue of nib files is a bit annoying. Other Java development environments have their own user interface tools that build Java source for your application, but XCode doesn’t. However, a third party has come up with nib4j – a Java library that converts nib files into Java. This, on the face of it is a good idea, except there’s bound to be a small consequence on launch time, as the nib file is converted ‘on-the-fly’ within the target application.

One day, everyone might use the XUL specification for their user interfaces, and we might not have such a problem. Until then, this looks like a good workaround. For less than one third of the price of JBuilder, XCode 2 plus nib4j should provide a workable environment for developing Java programs for MacOS X. The resulting Java won’t be platform independent as it’s pretty likely that nib4j uses the Macintosh extensions to Java.

So, why not use one of the open source Java build environments, like Eclipse instead? This is a good question. I love Eclipse, but it still suffers from the no-split-editing issue. Version 3.0 is due out shortly and this will also support code folding. You can also get commercial interface builder plugins for it. All sorted! Or maybe not..

The problem with all user interface builders is the code that they generate. You get a monolithic mess of code which describes all of the widgets and it’s a bit of a minefield to modify, either as code or as a user interface model. One slip and you can find that your widgets are renamed and the rest of your code doesn’t work. Anyone who has developed anything but a simple Java program will know this. My workaround is to hand code the user interface. I use and/or develop Java classes that construct the user interface to my rules and requirements. If I want to follow Sun’s look and feel design guidelines, I can simply build a class accordingly to ensure spacing, fonts, widths, distribution of widgets etc. follows those rules. I end up with nice looking code that is easy to modify and still keeps the rest of my application working. Stick a front-end on the classes to parse XUL definitions and you’re almost home.

XCode 2 looks like it will be a good move forward, but, it won’t be perfect. But then, nothing is.