Alex headshot

AlBlue’s Blog

Macs, Modularity and More

What's in a name? Eclipse, Callisto, Europa

2006, eclipse
The Next Total Eclipse

One of the hardest problems in any developing system is coming up with a coherent taxonomy that elloquently describes the different parts of a system in a concise manner. Sometimes that job is easy, sometimes it's hard, and sometimes things take a life of their own.

When the codename of Callisto was being chosen, there were many entries about what name to call it. (My suggestion was total eclipse, which whilst it wasn't accepted has at least made it into the animated gif :-) It seems likely that the name following will be Europa or one of the other moons of the solar system. But either way around, Callisto has come to mean things that it wasn't originally intended for.

Callisto was a codename given to a simultaneous release of the ten Eclipse projects, in order to make it easier to adopt/use the ten Callisto projects simultaneously. The problem is that Callisto has been interpreted to mean other things; so where it originally meant to be the simultaneous release of these projects, it has been interpreted as other statements such as although simultaneous release is what the projects said, the Eclipse community heard integrated product. That's a valid desire, but a much harder problem. The problem is that words come to mean something other than the original intent of the word.

The same problem effects Eclipse in a more general way. Because of how Eclipse has grown, most developers tend to associate the word Eclipse with a Java IDE. Certainly, that's where Eclipse got its roots, but the Eclipse foundation is a small group of people whilst the developers on individual projects (Eclipse BIRT, Eclipse CDT, Eclipse JDT) are often staffed by Eclipse foundation members (as opposed to the foundation staff themselves). The foundation organises things like EclipseCon as well as ensuring that the Eclipse website is operational.

The big problem comes from attempting to distinguish the Eclipse JDT (Java Development Toolkit) from the Eclipse platform upon which it's built. Indeed, one of the selling factors of the Eclipse platform (or Eclipse RCP, if you prefer) is that it can be used for any application -- including non-IDEs -- but using a coherent user interface, with the added bonus that it can be integrated into any Eclipse-hosted application. Trying to encourage the adoption of the Eclipse framework for use in client-side applications always ends up with comments like 'But we use IntelliJ' or inevitably some tangent about SWT vs Swing. It also doesn't help that both CVs and recruiters are looking for people with 'Eclipse' skills, when they are probably looking for 'Eclipse JDT' skills.

The problem recently resurfaced in a bug about Eclipse IDE. Unfortunately, long-time members of the Eclipse community know the difference between Eclipse JDT, Eclipse PDE and Eclipse SDK, and don't see any problem with the taxonomy as it currently stands. But the average Java developer who goes to www.eclipse.org and clicks on the download link is given the option to download the SDK by default. The fact that it comes with PDE as well as the source for the entire platform isn't particularly relevant to them (and if you strip that and the help out, you can get down to a more reasonable 40ish meg, as I made available with Maclipse Lite).

At the end of the day, whilst there is a separate distinction made on the website between the 'Eclipse top-level project' and others, and whilst it's being pushed on people as the Eclipse SDK (when it would be better to call it Eclipse JDT and then ship PDE as an extension if required) then this problem is going to continue. Does it hurt the adoption of Eclipse, the Java development environment? Not really. Most developers will continue to download and consume more bytes than they'll use, and won't be any the wiser. Does it hurt the adoption of the Eclipse platform as the basis of rich client applications? I think that it does; or at least, hinders it. There simply aren't as many Eclipse RCP client applications that are being used, despite RCP being launched a year ago. Partially, that's down to inertia in the people who are associated at the fringes of the Eclipse community who don't appreciate the difference between the products hosted at the Eclipse website. Hopefully Callisto may help to advertise the different products again, but following the Apache example of ensuring that the projects are partitioned appropriately (e.g. the webserver known as apache is available at httpd.apache.org, and it's just a valid top-level project as (say) ant.apache.org or maven.apache.org. There's no confusing website with 'The top-level Apache project' and then other subsiduary projects elsewhere.