Growing the future
Last year, at about this time, I wrote a lengthy, omnibus post called Eclipse has a future. It’s purpose was to capture some of the challenges that are facing the Eclipse community, and describe how the work that we were doing in the e4 Incubator Project could help to address them. Since then, our investment in that work has continued to grow, and we are now ready to ship a new version of the Eclipse SDK, built with technology that has graduated from the incubator, called the Eclipse SDK 4.0 Early Adopter Release.
I’m going to talk about what it is about Eclipse 4 that makes it interesting and important, but first I wanted to say a bit about why we grew the tagline “Early Adopter Release”.
An Early Adopter Release
As I noted last year, the Eclipse Project developers have known for quite a while that we were going to have to innovate in some significant ways in order for the base platform to continue to be compelling in the face of changing pressures in the industry — notably, a range of new technologies for building desktop apps (e.g. AIR, Silverlight, etc.) and the push towards using the web to deliver “desktop grade” applications. At the same time, however, many of our consumers were looking for the strongest possible backwards compatibility / stability so that they could continue to move forward with the release train without needing to invest in responding to changes in our layer (or any other one they depended on, for that matter).
In addition, we had begun to feel that the complexity of the platform code itself was preventing us from growing our community. More than ten years of development had left the code in a brittle state where almost any significant change would break more places than it fixed, making it extremely difficult for new developers to get involved.
The result of this was a conscious splitting of our focus into an ongoing development stream, Eclipse 3.x, where we could continue to offer the strongest possible backwards compatibility and stability, and a brand new project, the e4 Incubator, where we could work on the kinds of major innovations and code transformations that we believed were necessary. As the work in this incubator matured, it would move outward to the most appropriate place: some to other projects at Eclipse.org, some to our Eclipse 3.x SDK (as the flexible resources work did in 3.6), and some to a new “forward looking” Eclipse 4.x SDK, which would “organically” become the focus of Eclipse based development as it proved its worth.
So here we are in 2010. We’ve gone from a prototype — last years “0.9″ release that used significant chunks of old code as “shims” to get things running — to a real Eclipse SDK built on some powerful new underlying technology. The thing is though, this really is new technology. It’s not like we went in and tweaked the implementation a bit; we actually gutted the workbench implementation and started again.
The good news is that it seems like our bet has paid off. If you look at the pace at which the new version of the workbench has come together, it’s obvious that this code is much easier to work with. Personally, I’d say we’ve seen about a milestone’s worth of improvement each week for the last month or so. Over all, the Eclipse SDK 4.0 is completely usable for development. The team has been running on it exclusively for at least a month, and the drive to eat-your-own-dog-food has gone from a painful experience to one that feels just like working with Eclipse 3.x (except that it looks nicer ).
The thing about dog-fooding though, is that it works through the scenarios that are most important for the people working on the code, and basically nothing else. It’s great at getting something we can use, but not so good at covering all of the myriad ways that the community has built on top of us, which gets me back to why we’re calling this an “Early Adopter Release”.
We need your help.
To get from the current state to something that is solid, bug free, and complete enough to be included in a release train (or used to ship product) is going to take your input. We need to know where the changes we’ve made impact you and your uses of Eclipse. We need to know whether there are things that are missing that you must have. We need to know if there have been performance impacts… Basically, we’re asking you to invest enough time to take the Eclipse 4.0 release and load your plug-ins and projects on top of it, and then tell us what is working and what isn’t. And, in case that wasn’t enough, we’re asking you to continue to work with us over the course of this year, re-trying milestone builds and helping us verify that we’re converging to where we need to be.
Now, I wish I could tell you that it would be immediately obvious how this was going to benefit your work. I think there are some very compelling things about the new workbench, but I honestly can’t tell how important they’ll be to you. Really, I’m asking for your help here because I really do believe that this is the future of Eclipse, and I know that it will be great with your help, or it will die on the vine without it.
The one thing I can offer in return is an absolute commitment to be responsive to your input. Our goal is to have every milestone on the road to 4.1 be a “mini-release”; one that is visibly more complete, more capable and more solid than the ones before it. To do this, we will be strongly focused on the issues that you report to us — to the early adopter goes the spoils (er… bug fixes).
What’s there now
If you’re looking for the full list of what’s new in Eclipse 4 you should check out the New and Noteworthy. I’m not going to reiterate all that, but I would like to talk a bit about some of the technological pieces that have graduated from the e4 Incubator, which are the basis for this “newness”.
For example, the most immediately visible change you see when you start up Eclipse 4 is the new look and feel:
This is a great, fresh new look with a modern style and excellent use of whitespace to reduce visual clutter. But, in addition to being some best-of-breed design work [no, I didn't have anything to do with it] this also represents the first time where the appearance of the workbench — everything from the background colour of the main toolbar to the radius of the curve on the folder tabs — is controlled by CSS.
Why we believe this is important, is that it simultaneously gives people building RCP apps and products based on the SDK much more control over the look (i.e. the “branding”) while making the “language” of that control be one that makes sense to designers (i.e. instead of requiring them to know the internals of our Presentation API. Ugh!). It also opens up opportunities for people building apps that contain embedded HTML content to share more of their design resources.
Just as an example, here is an ugly, but definitely um… different look we rolled using only CSS changes:
The underlying SWT changes to support this work were done by the SWT team as part of 3.6 development (with a couple of tweaks since then). The CSS Engine itself was contributed by Angelo Zerr, with ongoing development from several others. To see an example of how you can use this new support in an RCP app, to excellent effect, take a look at Kai Tödter’s Contacts Demo.
Also, if you are interested in pushing the limits of what you can do with the CSS support, please come talk to us. There are definitely places where we would like to provide even more flexibility, and we know the workflows around editing the CSS could use work. Knowing what would be most valuable to the community here would be excellent.
Despite being less immediately visible, the most critical change in Eclipse 4 is the switch to a modelled user interface.
Essentially, the entire structure of the application’s user-interface is represented as an EMF model. This model has been carefully tuned so that it has strong separation between unrelated concerns, and is layered so that Eclipse 4 based applications can incrementally take only those pieces they actually need. This is a significant advance over the “take everything and prune out the bits you don’t need” approach used in Eclipse 3.x (and earlier) RCP applications. What this actually means is that people building new Eclipse 4 based applications do not have to include any of the scaffolding that is specific to the workbench’s use of the model, nor do they have to include any of the code that supports backwards compatibility for 3.x apps, if they don’t need it. We believe this new way to work is sufficiently important that we have christened it the “Eclipse 4 Application Platform”.
Note that this does not imply that you must give up 3.x compatibility in order to build RCP applications in 4.x. We continue to be committed to supporting full API compatibility between 3.x and 4.x, so building Eclipse 4 based, traditional RCP applications is still supported. It’s just that once developers start using the Eclipse 4 Application Platform, the benefits will be obvious.
At the workbench level, the flexibility we get from the use of the modelled user interface, together with another piece of technology newly graduated from the incubator, hierarchical contexts, also opens up brand new capabilities for 3.x compatible applications. In this case, by separating the application code from the context in which it is running, we can remove many of the artificial constraints imposed by the 3.x workbench. Dependency injection is used to provide the application code with the values it needs without requiring it to know where they came from, and in turn, the 3.x compatibility support makes use of this to ensure that all traditional change notification, data binding, etc. behaves as expected.
You know, reading that last paragraph, it’s clear that this is a case where a picture would definitely be worth the proverbial thousand words. Here is an example of a common workflow for us on Eclipse 4.0 that would be simply impossible to do in 3.x:
What you are seeing here is the completely unmodified 3.x Console view being displayed in the same stack as the editors. We like this because it’s a great way to give views like the Console more screen real-estate, but every 3.x user will tell you “You can’t put views in the editor area(!)”.
Really, this is about making the decisions relating to where views and editors show up (for example) a matter of policy rather than being hardwired into the implementation. Because, in 4.0, these policy “add ons” can be done by simply controlling what transforms are possible on the model, the code to implement them is very easy to write, is typically all held in a single class, and can be changed to support the needs of your particular application. For anyone who understands what the equivalent code in 3.x looks like, this is one of the clearest pieces of evidence we have that the new modelled UI is much easier to work with.
Where we go next
Before I go on, I have to say I’m absolutely humbled by how much effort everyone has put in to get us to where we are today. From the “old school” platform committers, to the new ones we gained because their work graduated from the incubator (Brian de Alwis, Kai Tödter, Yves Yang), to all those who continue to work on cool new technology in e4, to the many who have helped us with the design, and the many more who tested (with special thanks to Stefan Mücke), commented, documented… All of you have my greatest respect. I hope you all know we have built something great here, and we ought to be proud of it.
The thing is though, we also know one other important thing: We’re not done.
And we’re not done in an at least three significant ways:
1) plugging the holes
You don’t have to look far when playing with Eclipse 4.0 SDK Early Adopter Release to find places where there are bugs and things that are just outright missing. I’d apologize about this, but the truth is we got as far as we needed to so that our “early adopters” can help to guide us the rest of the way.
We have bugzilla for the bugs and a wiki page that captures the most obvious missing features. We know that there’s lots more work to do, and we’re going to do it.
2) graduating more
Even though we did see some important new capabilities graduate from the incubator, there is lots more work being done there that hasn’t graduated yet. We know that’s the natural order of an incubator — things will graduate when they’re ready — but what’s important is that we continue to push to make the level of investment it takes for that work to reach maturity.
As an example, for those who’ve been following e4 since the beginning, one of the most obvious missing pieces in Eclipse 4.0 is the Eclipse Application Services (a.k.a. “the 20 things”). Fundamentally, we still believe the EAS are going to be important for the future of Eclipse; particularly if we want to start looking at building plug-ins in languages other than Java. We did make some progress on this, this year, but we didn’t get even close to far enough for it to graduate as part of the 4.0 release. I’m disappointed, but I know we won’t let this one go. Stay tuned for more in the weeks ahead.
3) continuing to innovate
So listen, let’s say you’ve got this great idea about the next big innovation that we need, and that you are looking for just the perfect place to make it happen. Well, have I got an incubator for you!
Seriously, the e4 Incubator is intended to be a place to experiment, push the boundaries, whatever-it-takes on an ongoing basis. Just because Eclipse 4.x has started doesn’t mean its one burst of innovation is over. If you have an idea for something new, please come talk to us.
I was very happy to see that Olivier suggested bringing a JDT related project into e4 on improving support for Java-like languages. I think that’s a great idea, and I hope he can get enough critical mass to get it going. If you’re interested in that possibility check out the discussion on jdt-dev.
Anyway, even for me, this has been a marathon post. I hope that it helps to give you an idea of what we’ve been up to. Please give Eclipse SDK 4.0 Early Adopter Release a try, and tell us about your experiences.