Alex headshot

AlBlue’s Blog

Macs, Modularity and More

ObjectivEClipse project closing doors

2010, eclipse, objectivec

My first object-oriented language was Objective-C in the early nineties, and I've been a devotee of the language for some time. When Java was released in 1995, I remember being able to transition into the UI and object orientation fairly painlessly; and although I never left my NeXT box, time moved on and I went into Java development – and ultimately, onto Eclipse.

I picked up Objective-C again when I bought my first TiBook in 2001, but it wasn't until the release of the iPhone in 2007 (and the jailbreaking scene) that developing Objective-C apps became 'cool' again. Since then, interest in Objective-C has once again risen; and even though it feels clunky (in comparison with newer languages like Java or C#), the language has certainly evolved – with exceptions, blocks, threading and not to mention improvements in technologies like OpenGL, OpenCL and Quartz along the years.

I've often wondered what people see in C++ when Objective-C is available, and has been so, on the gcc platform for ages. There's been a long-running GNUstep clone of AppKit and friends, and other conversion kits like The Cocotron enable Objective-C based applications to be compiled for other platforms (for more details, see Cocoa with Love). Unlike C++, Objective-C classes generally avoid the fragile base class problem, and can dynamically link in newer versions of frameworks and perform framework-dependent versions – arguably, why it's possible to write iPhone apps that run on the latest-and-greatest hardware versions, but still enable the same binary to run unmodified on older versions with weak linking.

Everyone's opinions of IDEs differs, but those who have grown up with Eclipse can see where the advantages over Xcode shine. Unfortunately, the CDT project only natively supports C and C++ – althouhg there has been an enhancement request to support Objective-C in CDT for some time. (It was first raised in Eclipse 2.0 in 2004.) It's currently got 67 votes, but it's really up to the community to make it happen.

Last year, I proposed the ObjectivEClipse project on Google Code as a way of trying to advance the support of Objective-C in CDT. The hope was with enough interest, it would be possible to fold that back into the main CDT and make it a default part of the CDT installation.

Sadly, that project has failed.

There's a number of reasons why it didn't take off. Predominantly, the main one was a lack of interest in making it happen. (That's not the same thing as a lack of interest in it happening.) There were a few contributions; Ryan Rusaw did an excellent job in extending the parser to support Objective-C's blocks, which has been made available (but not implemented outside of Apple's gcc and the clang project.

From a technical perspective, although it's possible to configure a new language in CDT, there's a lot of internal packages that are shared between the C and C++ plugins which aren't conducive to an externally developed language plugin. Secondly, in looking at the possibilities of upgrading the Objective-C support for CDT 6 (in Eclipse 3.5) to CDT 7 (in Eclipse 3.6), it's become clear that the CDT parsers for C have been significantly refactored, breaking the existing ObjectivEClipse parsers. Even before this refactoring, in order to hook in the parser to the existing code required more than desirable duplication of code in the parser directory and others.

Wouldn't moving to Eclipse Labs help?

Putting aside the fact that the Eclipse Labs is a relatively recent creation (and ObjectivEClipse was asked whether it wanted to be part of the beta test), having availability has never really been a problem. The key is whether there's an interested set of developers, who develop in Objective-C and use Eclipse as their preferred IDE. Where the project is located wouldn't really change that dynamic; even after promoting it via my blog, on the CDT mailing lists, and on Twitter (including at NSConference), it's clear that there's a small number of people wanting it to happen, and an even smaller number of people interested in making it happen.

Even if there were, the arm's length approach to Objective-C support (if you build it, it can come) really doesn't work for the development of a new language, particularly when refactorings occur. That's not to say that the CDT team weren't helpful; they were responsive to requests for information, and even some of the CDT team now run Mac OS X. But there's a long-running impression that Objective-C is just for Macs, even when it works on Windows and Linux. Conversely, the existence of C and C++ on many platforms is treated as the de-facto standard, and so the CDT project supports these out of the box.

But projects like Wascana live on ...

Doug has been a long term supporter of CDT on the Windows platform. Although it's not possible to host or distribute GPL code from Eclipse.org, it is from Eclipse Labs, and the Wascana project lives there. However, this is really a packaging of the standard CDT with required binaries for the Windows platform – it's not a set of code extensions. It's really just a P2 Generator and some gcc packages, compiled with MinGW to make for an easy Windows install.

Would a DVCS help?

Being able to pull changes as they happen from the Eclipse codebase is one way of picking up on changes to the code as they happen. In quite a few cases, this is enough to keep up-to-date with the changes – but it's not enough. If the parser changes significantly, or changes are created by duplication, then refactoring isn't going to be included even with a DVCS.

In any case, Eclipse Labs doesn't support Git so that would be another problem – and even though Git is the de-facto DVCS of the future for Eclipse, the CDT project isn't part of the git.eclipse.org cloned respositories. That's not to say that some haven't created git clones of cdt-core – but it's a manual process, and is still falliable. Whether this would have been in place at the start would have avoided some of the bulk copying is an open question; but ultimately, a fork is only good if it can be folded back in at some point – and that was never likely to happen.

Is this really news?

Well, the activity on the project page (combined with the activity on my github clone) really shows that not much has happened for a while. Part of that can be attributed to the same time that Apple killing off ZFS since much of my development focus has been getting that back on track (and merging in the OpenSolaris codebase).

There's also the thorny question of Apple's policies and Section 3.3.1. There's been a long-term clause which states that Xcode must be the only tool used to build iPhone applications for submission into the AppStore; though it doesn't prevent other tools being used in addition to that. However, it's become increasingly clear that although development of Objective-C tools for other non-Mac systems is possible, it's the iPhone (and iPad/iPod Touch) platforms that are driving the Objective-C resurgence. In fact, just this month Objective-C made it into the top 10 languages on the Tiobe report (note: site is Slashdotted at this time), presumably through the Apple device strategy.

The future

There are those who want CDT to achieve world domination, and there's hope that this might include Objective-C at some point down the line. Certainly, I think that the usefulness of Objective-C as a language exceeds just a single manufacturer; the fact that clang and gcc both support Objective-C means that you don't need to be on closed platforms to write Objective-C code. However, it's my opinion that an Objective-C extension to the language has to happen within the CDT upstream source in order to survive refactorings instigated by other CDT languages. As it currently stands, ObjectivEClipse is firmly wedded to CDT 6.0, and there's no plans to change this at any time in the future; so, once CDT 7.0 comes out this month, the purpose of ObjectivEClipse effectively grinds to a halt.

I'd like to thank those that supported the idea of Objective-C in CDT, and in particular those that offered their time and advice at prior EclipseCons and on the CDT mailing list to give it the best chance so far.