Today marks the arrival of the Eclipse 3.5 (Galileo) release train, bringing in with it a year's worth of accumulated goodness. Ian Bull has already provided his top ten list, but as a Mac developer one of the most important things to me is the Cocoa support.

For those that don't know, the underlying APIs on Macs have been based on two different concepts; the object-oriented framework that once was Nextstep (called Cocoa in Mac OS X) and the older legacy C-based API from Mac OS 9 days (called Carbon). Although both can be used to write applications, interact with the same (visual) widgets, and have much the same access, ever since Mac OS X was released the future has always been Cocoa. (The iPhone has a predominantly Cocoa based runtime as well.)

When the Eclipse Mac port kicked off (which was by and large when I became involved with the Eclipse community, having only seen/used Eclipse in an IBM-related position prior to that), the decision was made to go down the Carbon route. In part, this was due to the familiarity of the APIs with respect to other UI toolkits available, and also lack of exposure to Objective-C in general. Apple has kept updating Carbon in subsequent Mac OS X refreshes, but the pace of development has mainly been in the Cocoa space. And given that the Carbon libraries were predominantly 32-bit, the cost of upgrading/maintaining those in a 64-bit world were too high; Apple has explicitly said that Cocoa is the 64-bit way of the future.

Other high-profile apps have been based on Carbon for some time - QuickTime and Finder are two such examples. But although Mac OS X has been able to use more than 4G of memory (by creating multiple 4G slices where necessary), it isn't until Snow Leopard that the Cocoa applications have had native 64-bit access across the board. Snow Leopard might be the last Apple OS that will run on 32-bit machines; if it weren't for the fact that some of the initial Mac Minis were 32-bit, Snow Leopard probably would have had a 64-bit only moniker as well.

Apple has also made sure Java developers move forwards with 64-bit support, though arguably there's not much for Java developers to do/care, since the JVM handles all the abstractions for non-native code. The latest Java 6 is only available on 64-bit Intel Macs, which may have performance improvements over its Java 5 counterpart (which has 64-bit and 32-bit mode).

This brings us back to Eclipse on the Mac. There are now three downloads you can get:

• carbon.tgz - the older, Carbon-based UI which should run on PPC and Intel machines but only be capable of Java 5 32-bit access
• cocoa.tgz - the newer API, able to run on PPC and Intel machines, also only capable of 32-bit access
• cocoa_x86-64.tgz - only available for Intel 64 bit platforms and 64-bit JVMs (Java 5 or Java 6)

To configure which JVM you use by default, you need to run /Applications/Utilities/Java Preferences.app which specifies the order in which it tries to launch a JVM. If you download the x86_64 package, you need to make sure that Java 6 (64-bit) or Java 6 (64-bit) is at the top of the list. Otherwise you'll need to ensure that Java 5 (32-bit) is at the top of the list.