Chris Aniszczyk: ‘e4 can be thought of essentially as RCP 2.0′
Interview with Chris Aniszczyk on Eclipse’s increasing adoption as a runtime technology, modularity and e4.
Eclipse has come a long way since its beginnings as a Java IDE, and recently there has been a surge in interest in Eclipse as a runtime technology. JAXenter caught up with Chris Aniszczyk, moderator of the Eclipse Platform Day at JAX 2010, to ask him why Eclipse is becoming so popular as a runtime technology, and what impact e4 and OSGi are having on the community.
JAXenter: Eclipse is becoming more popular as a runtime technology. New runtime projects like Virgo, Gemini and Jetty are completing the Eclipse Runtime Stack. What does Eclipse have to offer developers, as a runtime technology?
Chris Aniszczyk: Eclipse has definitely evolved from its tooling platform roots and has entered the runtime space with the EclipseRT effort. There are about 200 projects at Eclipse.org now and many of them have runtime Aspects. A lot of people are still unaware of EclipseRT, but it essentially represents the name given to this portfolio of Eclipse runtime projects. Developers can use EclipseRT technology to build rich desktop and web applications, as well as applications platforms. EclipseRT includes some of the following capabilities:
* UI layers with RCP, RAP, or Riena
* Runtime containers such as Jetty and Equinox
* Persistence services with EclipseLink
* Data reporting support from BIRT
* Data modeling with Eclipse Modeling Framework (EMF)
* Remote communication and distributed OSGi with ECF
* and so on…
In the end, I think the combination of the EclipseRT projects and Eclipse tooling make it a compelling choice for developing and deploying enterprise applications.
JAXenter: What are the weaknesses in the Eclipse Runtime Stack?
Chris Aniszczyk: Well, I think one of the major problems Eclipse has is that many people still think of Eclipse as a tooling platform. It’s hard to discuss runtime technology with people that simply view Eclipse as tools. We are changing that with the EclipseRT brand. Another weakness in my opinion was the lack of a cohesive example showcasing the power of Eclipse runtime technologies. It’s great to talk about runtime technology, but if you don’t have a good example to show people so they can see the benefits… it’s almost a hopeless cause. Thankfully, I think EclipseRT is finally getting there with the Toast example.
Toast is an example application meant to demonstrate a wide range of EclipseRT technologies and operates in the telematics and fleet management domain. It’s an easy to relate to example, and it’s not trivial, so people can see the power of EclipseRT. I also think the recently released OSGi and Equinox book helps, as a common complaint from people is the lack of documentation. The OSGi and Equinox book serves as a great primer for EclipseRT and I highly recommend people reading it if they are interested in runtime technology at Eclipse.
JAXenter: Adrian Colyer from the Spring dm Server (Virgo) project recently said that the cost of adopting enterprise OSGi, can outweigh the short-term benefits. Why is this? Is OSGi not yet ready to become a mainstream technology for Enterprise applications?
Chris Aniszczyk: I think that a lot of people took his quote out of context. I can’t speak for Adrian of course, but I think part of what he meant is that modularity doesn’t come for free. There are many of us convinced that we are writing “modular” code, but until you have a modular runtime like OSGi that enforces contracts, you can’t really see whether your code is modular or not. I have converted quite a few legacy projects to use OSGi and it was amazing to see the holes in the architecture once you started to create OSGi bundles and enforce contracts. The fact that modularity is hard makes OSGi a bit difficult for people in the beginning. However, software is only getting more complex and I personally believe you really need something like OSGi to help manage that complexity.
To really answer your question, I think OSGi is evolving to meet some of the desires of the enterprise with its OSGi Enterprise Expert Group (EEG). They recently released a set of enterprise related specifications which should help things.
On a side note, for an entertaining read about the problem of selling modularity, I highly recommend reading Hal Hildebrand’s blog post…
JAXenter: You are running ‘An Introduction to EclipseRT, Equinox and OSGi’ at the Enterprise Eclipse Day. What can attendees expect?
Chris Aniszczyk: As the title says, attendees should expect a solid introduction to EclipseRT. I will talk about a bit of the history of Eclipse as a tooling technology and how we moved into the runtime space. I’ll go over some of the projects that are part of EclipseRT and where things are headed in the future. I will also demonstrate the EclipseRT example application known as Toast. Attendees should expect to leave with a good understanding of what EclipseRT is and understand how they can play with Toast to get a more in depth understanding of how the EclipseRT technologies tie together. In the end, if you have any interest in EclipseRT, I highly recommend attending.
JAXenter: You will also moderate the Eclipse Platform Day. How do you foresee the Eclipse e4 project, impacting the community?
Chris Aniszczyk: Yes, I’m thrilled to be the moderator of Eclipse Platform Day and hope people enjoy the program. I think the e4 project will have an interesting and positive impact on the Eclipse community. In general, anytime a technology evolves to a new level there’s always tension. For example, just look at what is happening with the Perl5/Perl6 communities and what happened with Python when it broke backwards compatibility. It’s hard to evolve technology without upsetting some people. However, the Eclipse platform needs to evolve to stay relevant… any technology needs to do that. The e4 team consists of a lot of Eclipse veterans (and newcomers) who understand the mistakes of the past and are building a platform to last for another generation.
I also think people need to understand that e4 can be thought of essentially as RCP 2.0 (to simplify things) and that the e4 team is working on an impressive compatibility layer so people’s investment in Eclipse technology can still run on e4.
In the end, the Eclipse platform is almost a decade old, it was in need of a rewrite to fix some mistakes and modernize the plumbing. I’m sure we will make some mistakes again but as long as we evolve, we will keep moving forward and we will keep the Eclipse community happy.
JAXenter: You recently joined Red Hat. What does this mean for your Eclipse commitments?
Chris Aniszczyk: Why yes, I did. Red Hat is a great company that understands the value of open source and is a pleasure to work with. My Eclipse commitments will remain intact, if not stronger. I will remain as co-lead of the Eclipse Plug-in Development Environment (PDE). My focus areas are on making Eclipse successful and improving the status of Eclipse on Linux. On the whole, I’m still strongly committed to the success of Eclipse.