Callisto, retro Eclipse

The next big thing at Eclipse is Callisto. If you expect a nice new technology project that is codifying a cool technology for use inside Eclipse, you will be disappointed. Callisto is a major shift back to big bang releases. Callisto is a synchronized release of all Eclipse?s plugins.

Why is this bad? It is bad because it kills one of the major advantages of components: incremental releases and the possibility to mix and match configurations. Component models like OSGi promise a world where you can pick the components you need from different sources, calculate dependencies and then run them together. Once you go to synchronized releases you loose that advantage because you basically treat the components as object files that are linked into a single image.

Callisto is driven by the desire to get greater reliability; there were too many bugs caused by incompatible components. Obviously this is bad, and I am the first to admit that OSGi is not a full proof solution to this problem, but we are trying. However, the gut reaction to revert to the big bang world and test the hell out of it to get the required reliability is just not the future. When I was working for Ericsson in the nineties we had TMOS (Telecom Management Operating System). This was a synchronized release of many different applications like databases, tools, libraries, etc. Trying to synchronize a release of often buggy components and terrible dependencies was a nightmare. It became so bad that releases took two to three years to reach the market. In a fast moving industry that is just not acceptable. The advantage of a dynamic component model is that all participants can have their own release cycles; you should not have the bottleneck of synchronized release.

So why is Eclipse falling back to the old model of synchronized releases? These are very clever people that have done a tremendous job so far. It is hard to look in their hearts and minds but the Eclipse?s plugin/bundle development environment (PDE) indicates a world model gives a hint. The PDE tries to hide the complexity, dynamicity, and uncertainty of the real world from the developer. This is done so well that developers easily get lulled into a false sense of stability that just does not exist in the real world. Developing components requires one to take the instability of the world into account.

For example, in Eclipse 3.2 the target is treated as if this is the deployment environment, and not a temporary configuration; guaranteed to be different when you finally deploy. Note for example that there is only one target per workspace. This makes it easy to assume that if it works on your target, it works everywhere. Obviously it does not. Any bundle developer must consider its dependencies, minimize them, and think about versioning. The PDE should provide tools to have targets with alternative configurations it should have tools to visualize your dependencies and minimize them during packaging. But it should clearly not try to hide the dependencies from view as it does today, based on a false sense of stability.

I hate to bring it up because I feel like a zealot, but obviously the require bundle is a clear symptom of this world view. Require bundle is the transitive dragnet of software. It is easy to use and you are likely to catch the code you need. However, just like a real dragnets you catch lots of fish you do not need. Worse, due to its transitive nature that stuff in your net is connected to lots more stuff you do not need, ad nausea. Look at Maven, it uses a similar concept and has to download about 30 Mb of software before it can build your ?hello world? that has no dependencies except that is build with Maven.

Another tool that the OSGi Framework provides to battle the dependency monster is the service registry. Services provide decoupling because they have a clear contract without implementation and they have a clear binding and unbinding phase. The service model allows your bundle to adapt itself to the environment it runs in. As Richard Hall said: ?Your bundles are your configuration.?

By focusing on services, which are defined by their interfaces, bundles can become fairly decoupled from their target environment. Eclipse plugins rarely use the service model because the extension registry is better known (and better supported by the PDE) than services. The extension model focuses on extending and not on decoupling. The disadvantage of the service model is that it requires hard work in defining service interfaces that are good and do not break apart in the next release.

The only reason I get when I discuss these issues with Eclipse people is that they have legacy code which they can not change. I buy that because I know the constraints of real life and deadlines all too good. However, when I look at the PDE I think they currently promote creating future legacy code. For all new applications the 3 foci points should be: decoupling, decoupling, decoupling, and high cohesion.

Do not get me wrong. Component systems are state of the art and making it all work dynamically with 700 bundles is a daunting task. Eclipse never ceases to impress me with what they have achieved so far. However, In the long run, the synchronized release model is just not what the world needs. There is probably a long way to go, but we need to analyze the problems we run into with a dynamic component model, find the root causes, and provide tools to prevent those problems. Falling back to synchronized releases is not an option; it is throwing out the baby with the bath water.
Peter Kriens

posted by Peter @ Friday, June 30, 2006