Alex headshot

AlBlue’s Blog

Macs, Modularity and More

What's the future for Eclipse on the Mac?

Eclipse Mac 2007

With Leopard's recent release, the question of where Eclipse is heading on the Mac comes to mind. SWT on Mac uses Carbon, which is a (32-bit) C-based API that originally allowed porting between Mac OS 9 and Mac OS X. Partially, the reason for Carbon to even exist was to allow applications based on Mac OS 9 not require porting to the new Mac OS X APIs. (Roughly Drafted has some further background if you're interested.)

In any case, ever since Mac OS X was released, it was clear that Cocoa would be the framework for the future. However, when SWT was started on the Mac, Carbon was used, primarily because that's what AWT used at the time, but also because as a low-level procedural API, it worked closer to the way that SWT worked. (These are based on my understandings from reading about the situation; I'm not speaking authoritatively about this.) This causes some issues with the event loop; even now, there's still some issues in using AWT in conjunction with SWT due to the event loops (changes for the 'real' 3.3.2 are planned for Leopard support, which has changed slightly).

So, Eclipse is largely based on Carbon; but here's the problem. Carbon has been known to be deprecated for a while. Even some of the 'big' companies (Adobe, Microsoft) are only just moving off the Carbon train and onto the Cocoa train. Carbon still works in Leopard, but for how much longer?

In addition, the key thing with Leopard is that it's a fully 64-bit system. Tiger could use 64-bit memory, but the UI was only 32-bit, and the kernel therefore was also 32-bit. In Leopard, the core frameworks have been overhauled to give 64-bit through and through. However, this is only for those apps using Cocoa; Carbon-based apps are forever cemented to the 32-bit age. Given that Carbon is on the way out, there's no way this is going to be updated to 64-bits; and looking a couple of releases down the line, it may not even be present (for example, Classic, the Mac OS 9 emulator, finally shuffled off the Mac OS X platform; it can run on Tiger, but no longer on Leopard).

Apple has tried to encourage Java developers to use Cocoa before; Apple's Java-ObjC bridge was created to permit Java apps to use NSApplication and other key frameworks. In Leopard, this has finally been deprecated; the support pages have been marked as "legacy technologies" and a JavaScript pop-up window gives the warning "Legacy Document: Important: The information in this document is obsolete and should not be used for new development." You might be interested that there was (is?) work going on with carbon-specific OS ports in Eclipse's SWT project; Eclipse 3.3 and 3.4 have some support for interacting via org.eclipse.swt.internal.cocoa.Cocoa in addition to the Carbon APIs. It's not clear whether this approach is also deprecated, or whether this is part of a bigger plan to try and encourage developers to move towards to Objective-C (which now finally has garbage collection).

In any case, Apple has officially abandoned any new widgets (or APIs) with the Java bridge, so whilst NSApplication et al still exist, other new widgets (such as the core animations or resolution independence; read more about the new UI if you're interested) might not be accessible. Not only that, but when processes start up, they must either be 32-bit or 64-bit (it can't switch at run-time, although the same 'universal binary' can contain both programs). From the ArsTechnica review:

Fast-forward to WWDC 2007, this time in the 64-bit session, and the other shoe dropped. Though several non-GUI parts of the Carbon API that are shared with Cocoa will be supported in 64-bit mode in Leopard, the GUI portions of the Carbon API will not.

Yep, it's (finally) the end of the line for Carbon GUI applications in Mac OS X. Oh, sure, they'll be around for years and years to come, but the lack of 64-bit support is a long-term death sentence.

The last vestiges of the original Macintosh API are finally being put to rest. They've done their job and are being given a decent burial, I think. A slow, almost natural transition. Bugs will be fixed in the 32-bit Carbon APIs, of course, but no new features will be added. All new GUI APIs in Leopard and future Mac OS X releases will be added as Cocoa-only APIs.

Which brings us back to Eclipse. It's a 32-bit system running on top of Carbon, and the warning signs are clear; it's the past. What form will it take in the future? Apple's engineers have been working contributing support SWT in the past, as well as making changes in the way that the JVM on Mac works. There's a big interest in getting SWT- and Eclipse-based apps running on the Mac, but there's also a big interest in getting rid of Carbon. How long will Eclipse/Carbon survive before Eclipse/Cocoa comes on the scene?