The Architecture of Eclipse

Every Object-Oriented developer should study the architecture of Eclipse. Everyone who learns Object Oriented Programming (OOP) learns it from the perspective of "programming in the small". That is, they know it from the point of view of developing programs by a single developer or a small team of developer. However, when you have tens to hundreds of developers then a lot of tried and true ideas of OOP simply break down and cannot scale.

Now trying to understand the Architecture of Eclipse can be quite bewildering. It's the kind of feeling I had when I first encountered a framework called ET++. You could see all the amazing structures and the incredible result of it. However, it was simply difficult to grasp until the GoF book was published. There were patterns in the code, micro-architectures as Erich Gamma called them then.

Fortunately, Kent Beck wrote a book "Contributing to Eclipse" that gives you a glimpse of the architecture. It's not as well structured as one would want, nevertheless its better than nothing!

The most intriguing thing about the Architecture of Eclipse is that it has built on to it an "Architecture of Participation". Most users of Eclipse are perplexed when they see that a lot of functionality devoted to support the development of plug-ins. It's perplexing because most developers don't develop plug-ins in their day job. A more intuitive setup would have been to make the Plugin Development Environment (i.e. PDE) optional. Nevertheless it is there front and center, and it is there for good reason.

Developing plugins for the Eclipse platform isn't an easy endeavor. You not only have to grasp a new user interface framework (i.e. SWT and JFace), but you also need to understand a new way of structuring components. Nevertheless the obstacles haven't prevented the masses from creating hundreds of plugins. It's not much of an industry yet, more like a cottage industry, however it just might get there.

Deep in the bowels of Eclipse are the patterns and principles of how to "program-in-the-large". Kent Beck writes about different developer roles that is the committers, enablers, publishers, extenders, configurers and users. He put together some "House Rules", although they conver mostly enablers and extenders. It gives me the feeling that a lot of the book has yet to be written. Nevertheless I wish to draw extra emphasis on the rules for enablers. That is, what structures do you introduce to enable "programming-in-the-large"?

Rules for Enablers

• Invitation Rule - Whenever possible, let others contribute to your contributions.
• Lazy Loading Rule - Contributions are only loaded when they are needed.
• Safe Platform Rule - As the provider of an extension point, you must protect yourself against misbehavior on the part of extenders.
• Fair Play Rule - All clients play by the same rules, even me.
• Explicit Extension Rule - Declare explicitly where a platform can be extended.
• Diversity Rule - Extension points accept multiple extensions.
• Good Fences Rule - When passing control outside your code, protect yourself.
• Explicit API Rule - separate the API from internals.
• Stability Rule - Once you invite someone to contribute, don?t change the rules.
• Defensive API Rule - Reveal only the API in which you are confident, but be prepared to reveal more API as clients ask for it.

What you first observe is the rigidness on how to evolve API. This is expressed in more formal detail in the article "Evolving Java based APIs". It's an extremely tough read, however it's necessary.

These rules are a direct consequence of several fundamental criteria of moularity. That is, locality, reusability, composition transparency, unpluggability, continuity and protection. These criteria should be present in any modular system to achieve success. In fact, if you examined OOP closely, or even the java object model, you will realize that it breaks these rules in many places.