Eclipse has a future.

We’re getting close to releasing 0.9 of e4, so I wanted to take some time to talk a bit more about the context for why we started on this path, and how far we’ve gotten in the last year. To give this some structure, let’s look at a few of the big questions…

1) Does Eclipse have a future on the desktop?
2) What would an ideal Eclipse platform look like?
3) What is e4?

… and maybe a couple of more pragmatic ones too…

4) When is e4 done?
5) What can I do with e4 0.9?

Does Eclipse have a future on the desktop?

Easy answer: “Yes, but not if we sit still”.

I’m sure it’s not news to anyone in our community that, unlike in the early days of Eclipse, there are many credible threats out there when it comes to technologies for building desktop applications. Adobe AIR, Silverlight, even pure HTML5+JS, for example, can all be used to build rich, cross-platform desktop apps. For Eclipse to be a viable platform in this environment we need to innovate on many dimensions, including packaging/distribution/size issues, flexibility and richness of presentation, integration with other technologies and, most especially, ease of development.

We’ve got to get to the point where developers are choosing Eclipse because it’s both easier to use than the other technologies out there and because the results work better and integrate better than anything built any other way.

What would an ideal Eclipse platform look like?

Well, obviously it needs to address the issues above, but there’s more to it than that. To me, the ideal Eclipse platform is one that has the ability to move when there are new pressures on it. Technologies change, uses change, the community itself changes over time, and whenever that happens, either the platform has to be able to move with it, or we die.

The ideal platform should have a strong separation between presentation and implementation, and it should be dynamically configurable to run in the widest possible range of contexts. It should have the smallest possible number of “pre-canned” constraints, and it has to be easy for new people to start using it so that it can be discovered and consumed by whole new communities.

<intermission>

“But wait!”, some of you are saying, “for my uses of Eclipse, I don’t need any of those things. I just use the IDE to develop; I don’t care what it looks like. And besides, we’ve already built all our plug-ins. The most important thing is don’t break us.”

I get it. You’ve invested in Eclipse long enough to get something that works for you, and you just want the world to stop so you can get as much value from that investment as possible. That’s ok. You’re a part of this community too, and we need to support you. That’s why the focus for the R3.x stream of the SDK is the strongest possible backwards compatibility: If you ran on R3.4 or R3.5, we want you to move to R3.6 because it’s effortless.

But the thing is…

This post isn’t for you.

What we are talking about here is what it’s going to take for Eclipse to be relevant in another ten years. This is for those of you who care about making that happen in addition to getting the great day-to-day value you currently get. If you believe, like me, that Eclipse is simply too important to allow it to fade away, then read on.

</intermission>

What is e4?

A few years ago, the Eclipse Project developers were facing what seemed like an insoluble problem: We could see that our industry was heading toward another period of big change and the platform was going to have to react to it, while at the same time we continued (and still do!) to get more and more real-world, important products built on us — products that could not afford to deal with the potential for instability caused by major work on platform internals.

At the same time, we were (yes, finally) beginning to realize that we needed new blood; that the monolithic nature of the team, which had helped us make progress early on, was now hurting our ability to grow our community and potentially risking our future.

This was one of those times when things “just worked”. From those starting points, we have become a new community, based around the e4 Incubator project, that is made up of a wide range of people who are working together to build that “ideal Eclipse platform” for the future.

It’s been a wild ride (and we’re not close to done) but I have to say that it blows my mind how far we’ve come in the last year. I’m not going to go into the individual technology details, but I will point you at John Arthorne’s excellent e4 Technical Overview white paper for the full description.

When is e4 done?

Hopefully, e4 the incubator is never done; it will be there as long as there is a need for the platform to innovate. Today though, you’re probably more interested in:

· when things that are currently being worked on become part of the platform
· when Eclipse 4.0 appears
· when Eclipse 4.0 gets on the release train

We have always said that code that is developed in e4 will mature at different rates. Some of the things that are being worked on could simply be moved to the R3.x stream, once they meet the backwards compatibility and stability requirements. Personally, I’d like to see CSS skinning of the widget layer, improved web browser integration, and the flexible resources work all move to R3.6, but that’s still to be determined.

Some of the changes that are being made, however, are simply too fundamental to ever make it into the R3.x stream. Those will only appear in a new, separate development stream of the Eclipse SDK, with the first version, called “4.0”, shipping a year from now.

The thing to keep in mind though, is that a year from now the odds that Eclipse 4.0 will have been subjected to the kind of testing and tuning that it absolutely must have for it to be used as the basis for product delivery are pretty low. It will be, in the truest sense, an entirely new platform that is capable of hosting your plug-ins. Will it be backwards compatible? Yes. Will it behave in exactly the same way as R3.x, so that every possible subtle interaction with your existing plug-ins is supported? No. Wait… what?

This is probably the most critical part of understanding the Eclipse 4.x stream: Even though we plan to do everything we possibly can to make Eclipse 4.0 backward API compatible, either because of use of internals, or dependencies on unspecified timing/ordering behavior, or any number of other subtleties, it’s possible that your plug-ins may not run. Since the only way we will know about that is if you tell us, our success will depend on you making an investment in trying to run on Eclipse 4.0 builds:

We will work with everyone who does this and finds problems to either improve our own code, or help them fix the incompatibilities in theirs.

Believe me, I understand that we’re imposing on you; if you don’t see value in moving to the next Eclipse, that’s ok, we really do plan to develop the R3.x stream for as long as anyone is using it. But at some point, one of two things will have happened: either the Eclipse platform itself will no longer be relevant, or so much of the community will have moved to the R4.x stream that your consumers will be asking you to move too. My crystal ball doesn’t say when that happens, but I know it will.

In case that sounded too harsh, I must also say that this is going to be an organic process that is controlled by the consuming projects, not by us. The best example of this the answer to the question about when Eclipse 4.x gets on the release train:

We will not ask to put Eclipse 4.x on the release train until every other release train project with a platform dependency runs on it.

So, no it won’t be in Helios. However, it will be real enough at that point that you should take it, work with it, and help us understand what needs to be done. If you’re an RCP developer, you will be very pleasantly surprised by how much easier it is to get the look and feel you want. For the SDK, we plan to have every single view and editor that is in R3.6 also working on R4.0. That should be a good start on backwards compatibility.

What can I do with e4 0.9?

All that’s great, but we’re shipping something this week too. 🙂

The “e4 Compatibility Platform” is what we’re calling the main download for the 0.9 release. It’s not even close to being complete enough to be an “Eclipse SDK” yet, but it is enough for self-hosted development (using views and editors from R3.5(!)) and demonstrates well all of the things we’ve been talking about. Kevin McGuire wrote a great post that describes a perfect example of why we we’re so psyched:

“I think this really shows the power of the architectural concepts in e4. Not only do you get externalized styling, like you do in the web, but you also get a simple, composable model of the UI, abstracted above that of the widgets, which you don’t normally get in the web.”

Despite some immediately obvious missing pieces (like no save/restore of workbench layout, no main toolbar, no min/max behavior, and numerous small bugs), it’s definitely usable. For the last week or so, I’ve been spending my evenings using the e4 Compatibility Platform (with (SchemeWay) and Ahti Kitsik’s Virtual Word Wrap [edit: updated link] plug-ins installed) to write some wiki software in Gambit Scheme. For my use, this worked great.

I also know some people on the team are using the e4 compatibility platform for all development. Currently, that takes more perseverance than any of us would like, but the good news is that we know what the issues are, we just ran out of time to fix them.

In any case, just so there are no illusions about exactly how “young” this code is, here are some hints that I learned while using it:

If you can’t get a menu or keybinding to work, try the popup menu instead.

This is a symptom of all the myriad ways we have for hooking up menus in R3.x, some of which just haven’t been wired off yet. That’s a perfect example of the kinds of things that make it hard for new people to understand Eclipse R3.x development.
 

Don’t check the “always exit without asking” check box when you close the shell.

Until save/restore starts working, it’s painful to have to re-open/re-layout all of your views. You don’t want to exit by accident.
 

If you close a perspective, don’t immediately open that one again.

If you try, it silently fails. Instead, open any other perspective first, then you can open the original. I’m not sure why this is happening, but it’s just a bug.

Well, that’s where we are. Once R0.9 is out, we’ll be reviewing all of the work areas, identifying the missing pieces, and building the plan to get from here to Eclipse SDK 4.0.

In Closing…

Please, give the e4 Compatibility Platform a try. If you see the value in what we’re doing, please consider participating. We are entirely open to new people who want work with us on the existing development areas or on anything else that you think is interesting. Even if you don’t think we’re on track, come talk to us: if we’re missing something important, we need to know.

For me, I think we have hit the “sweet spot”: we’ve found a way to continue to work with interesting people, on interesting problems, innovating a future for Eclipse on the desktop, while still providing the backwards compatible, it-just-has-to-work, world that we must have on the release train.

I really am psyched!