Alex headshot

AlBlue’s Blog

Macs, Modularity and More

First (and last) thoughts on Eclipse 3.5M7

2009, crap, eclipse

Over the long weekend, Eclipse 3.5M7 was released. This is the last in the milestone series before the June release for 3.5. Between then and now, we have a handful of release candidates aimed at squashing bugs rather than adding any new features.

Given that I'm (slowly) working on ObjectivEClipse and working on EGit at the same time, I want to have a stable environment whilst also basing off the latest versions of the software, not least of which is to verify bugs have been fixed which ObjectivEClipse depends on. So, off to download 3.5M7 ...

The problems started when choosing a download for Mac. There's two versions available - one for Cocoa and one for Cocoa-x86_64. Mac users aren't accustomed to platform-specific downloads; after all, the Mac's fat binary format allows multiple architectures to exist in the same binary at the same time (aka Universal binaries). This has been used to support G4 and G5-optimised builds in the days before the intel switch, as well as supporting both the PPC and Intel builds since.

So why do we need to have a separate platform for Mac at all? Well, the SWT binary has an implicit dependency on the size of the pointers returned by the underlying native layer, and uses either int or long appropriately. So, the Java code, which deals with pointers, needs to be able to accommodate both variants. In order to do this, there's a SWT hack convention which uses a replaceable int/long combination, and there's two versions of the Jar that are built; one that has long pointers, and one that has int pointers. (If you've ever looked at the source code for SWT, you'll see things like private int /*long*/ ptr - a post-processing system reads in the source, swaps the comments, and then compiles it.)

OK, so having an x86_64 laptop, I download the x86_64 build. Seems reasonable enough. Eclipse launches, there is much rejoicing etc. However (and here's the cunning bit) Eclipse then fails dismally to be able to launch itself in a runtime Eclipse application, complaining with an error 'You must use a 64-bit JVM to load 64-bit SWT' or similar. Hang on - a running Eclipse instance is telling me that Eclipse can't run? Despite massaging the target.arch platform to get it to run x86 instead of x86_64, no dice. And it hosed the workspace, so I've had to roll back to a previous version (thank you ZFS!).

Unfortunately, that wasn't all my timewasting. In order to get to that stage, I had to re-download all the plug-ins that I needed to get up to speed, which included Mylyn, the Mylyn incubator web connector (which doesn't seem to have done much incubating recently - stick it in the main download, why don't you?) in order to hook up with google code as well as the real SVN plug-in, subclipse. Remember the good old days where you could have a separate plug-in install location? Good ol' P2 thinks you don't need that any more. Despite it being technically feasible to have more than one plugin repository, no-one seems to know how to do it, least of all the P2 wiki. In fact, earlier conversations seemed to suggest that whilst it was technically possible, no-one has tried it and thus it actually is buggy at the moment.

What really grinds my gears is that the new P2 update manager appears to go out of its way to prevent you from updating. Case in point, the above subclipse download. Plugging the update site into the update manager gives you the 'subclipse' category; if you select that, you get the combined set of the below features. However, the category includes both Mylyn 2.x and Mylyn 3.x support; great for people who might not have migrated to the latest and greatest whilst still providing support.

Alas, no, the P2 update manager requires you to have both Mylyn 2.0 and Mylyn 3.0 installed if you want to install everything from here; the cryptic 'Some constraints cannot be satisfied' message and the Finish button disabled. Were one to press the 'back' button in some misguided attempt to fix the problem (like deselecting the Mylyn 2.0 feature), the 'finish' button is dead in the water and refuses to move thereafter. You actually have to quit the update window, re-open it again, plug in the update site ... remember to deselect the 'Mylyn 2.0' feature, and you're good to go. Repeat ad nauseum with the other features you may have installed (google code web/mylyn plug-in, check style etc.)

What's mind-bogglingly clear is that no-one actually uses the update manager at Eclipse in order to update Eclipse. Initially, you could excuse the whole newness of P2 as explaining away any quirks; but frankly, even P2 was released too early last time around, and the update story hasn't got any better since. Witness the sheer number of .zip files that the automated build processes spit out on a daily basis (and the mirrors around the world who swell up holding redundant copies). How many copies of org.eclipse.osgi are there? org.eclipse.swt, of whichever binary build you have? Partially, this is due to the success of the EPP, which pumps out near-identical base builds with a different topping for the major use-cases of Eclipse - but realistically is the only way to get hold of Eclipse due to the state of play with update manager.

Participation in the Gallileo release train has a Must Do requirement for a P2-enabled update site. I've yet to see a project publicly put up a P2-enabled update site for updating Eclipse's M builds; I'm willing to bet that the majority of the Eclipse team simply download the latest version spat out by one of the build processes. (Mylyn is a notable exception; they have a weekly update site which I suspect most Mylyn developers will be hooked up with.)

I'll go further and say that Eclipse should stop building .zip bombs of the Eclipse platform. All we need is one (or a handful) of .zips containing the platform and update manager with some predefined (preferably small number) of update sites. If we want to install Eclipse, download and run the updater. One could very well argue about the contents of the minimal bootstrapper, but there should be one. Downloading new features should be a point-and-click exercise, not an exercise in Google site searches. And how about a combined repository for Gallileo artefacts, instead of a per-project URL? Maven has shown - for years - how this can work well, and Eclipse would do well to follow its lead. For example, a single directory of every plugin ever made, with the requirement of having a single global site.xml (or whatever P2 flavours you end up with) isn't a scalable solution. Not only does it suck if you are trying to find something, it's also a write-once repository; once you generate that site.xml, you're off to a losing start. Any changes, even if they're there on the web server, won't show up until it's regenerated. Maven has built up a well defined directory structure, so if you know what you're looking for, you know which directory to look (and then find a per-directory config, not per-repository config). One could expect a Mylyn bundle to be in org/eclipse/mylyn, for example.

Unfortunately, in the present, there simply is no good way to do updates from Eclipse using the built-in tools. Because of that, people shun using the update manager and download megabytes of bits every time, even if they don't need to. P2 focussed on the wrong problem (Wahey! We can install 17 copies of the same application from a single local cache of bundles!) instead of focussing on making Eclipse an updatable application. Granted, there are some technical advances (using pack200 compression for the Jars, for example) but it's all plumbing and no porcelain at the moment.

Anyway, I've given up with Eclipse 3.5M7. Not that there's no features, or that I don't want to help out testing, but simply because It Just Doesnt Work. Installing into Eclipse is a waste of time; downloading zips and then copying the contents (manually) into plugins/ and features/ (which incidentally, are still pretty oxymornic concepts; we're in the 'bundles' world now, and everything's a bundle) is about the only workable solution. Until Eclipse stops dumping out .zip bits and starts consuming its own update sites, it's not going to get any better.

PS gets it better than Eclipse Update does; however, after pick-and-choosing your favourite features, it still serves it as a giant zip blob. However, once you've got it downloaded, you can then consume additional features subsequently in incremental update forms. It's just a pity that they only support the 3.4.x streams rather than having a way of testing 3.5Mx streams.