The brilliance of Charles Shultz never ceases to amaze me. As far back as 1963, he knew that Eclipse was a big deal.
But even he had difficulty getting Lucy and Linus to describe Eclipse.
This brings me back to my recent discussion of a presentation I do titled “What is Eclipse?“. In this presentation, I start simple: Eclipse is… a Java IDE. I start here, because this is where most people are comfortable. I then take a pretty winding path that–with each step–broadens the definition of Eclipse just a little. Most of the initial discussion is concerned with getting the audience comfortable with the fact that Eclipse is a really a über flexible platform that can be easily extended to do just about anything.
In my last slide that discusses Eclipse from a technology-perspective, I completely blow the doors off the notion of Eclipse as a Java IDE and bring forth what is a shocking reality to many: Eclipse is… Runtimes!
At the core of Eclipse is a powerful component model named Equinox. Equinox is what makes all those plug-ins work together: it manages the dependencies between components, dynamically starts, stops, loads, and unloads functionality as required, and even allows for on-the-fly installation and uninstallation of components. In addition to components, Equinox also manages complex interactions between services and more. In short, something a big and powerful as Eclipse couldn’t possibly work without something as powerful as Equinox. Notice that I didn’t describe Equinox as “big and powerful”. It is, frankly, not all that big. In fact, it’ll fit on some pretty small embedded devices.
Equinox, as the slide states, is an implementation of the OSGi R4 core framework specification. In fact, Equinox is the reference implementation for OSGi R4.2 (work on R4.3 continues). Originally, OSGi was an acronym; but over time, that acronym has lost meaning, and now it’s just OSGi. OSGi was originally intended for devices that dynamically load and unload functionality as needed. One example of such a device is a “set top box” that can be used to dynamically load and run games and other more-useful kinds of functionality. The basic idea is that the functionality is temporary; it will eventually be unloaded and replaced with some other kind of functionality. Equinox and OSGi provide a much-needed component model for Java SE (JAR files are not components). But even more interesting that that, it provides a consistent component model that works across Java SE, EE, and ME. Imagine that: a single component model that can be used for desktop, server/web, and mobile/embedded applications.
So it was with Eclipse 3.0, that Equinox came into existence (prior to that, the Eclipse project had created their own component management framework). Around the Eclipse 3.1 time-frame, some smart folks realized that the component model that excels at making Eclipse-based applications run must also be good at managing other sorts of applications. They started building servers and other headless applications using Equinox as a base. Today many application servers run on Equinox and OSGi, including WebSphere Application Server, WebLogic Server, Glassfish, JBoss, JOnAS, and more.
But that’s just the start of runtimes at Eclipse. The Eclipse Communication Framework (ECF), a framework for building distributed servers, applications, and tools provides set of communications APIs and frameworks built upon existing protocols for developers to add communications and messaging to their own applications . EclipseLink, the Eclipse Persistence Services project–amongst its many features–provides the only OSGi-capable JPA implementation available today. Eclipse Rich Client Platform (RCP), embedded RCP (eRCP), and Rich Ajax Platform (RAP) support user interfaces across the desktop, mobile devices, and the web. Of course there’s the Jetty web server, and the relatively-new Gemini project that is providing important runtime components for OSGi-based servers. And there’s more. Much, much more. We created Eclipse RT to provide an entry point into the world of Eclipse runtimes.
If you’ve been following this series of posts, you’ll realize that I spend a great deal of time talking about Eclipse from a technology perspective. In fact, you’ve probably noticed that most of content of the talk so far has been about technology that comes from a single project (I’ve done that on purpose: as I mentioned earlier, I think it’s important to start with what people understand). But, Eclipse is more than the technology. Eclipse is… Open Source Projects.
