I am a committer

McQ's thoughts on things Eclipse

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!

Advertisements

Written by themcq

July 25, 2009 at 22:01

Posted in Uncategorized

Tagged with , , ,

20 Responses

Subscribe to comments with RSS.

  1. […] In my guise of “Eclipse SDK lead”, I just posted a new entry on my (too seldom updated) Eclipse blog. For those that are interested, check out: Eclipse has a future. […]

  2. Great post McQ!

    Kim Moir

    July 26, 2009 at 07:26

  3. I agree with Kim. That is a great post! Thanks for taking the time to put it together.

    Mike Milinkovich

    July 27, 2009 at 08:35

  4. Thanks, McQ. Yes this is much appreciated, and as always, I wish we could hear more from you.

    The voices of dissent have been heard. I encourage all of you who have taken a good look at e4 to comment, here, or in the blogosphere, especially those supportive of the initiative. The purpose of my post was to shake the community awake. There has been little talk about e4 outside of the project and the Foundation. Let your voice be heard. My biggest fear for Eclipse is apathy.

    Doug Schaefer

    July 27, 2009 at 16:56

  5. Thanks McQ. I’m looking forward to having Mylyn and Tasktop become early adopters of E4, and this post was very helpful in getting a beter grasp of timing. I’m particularly psyched about the improved web browser integration and the flexible resources.

    Mik Kersten

    July 28, 2009 at 14:35

  6. Thanks for a great post! Could you please replace your Virtual Word Wrap link with http://ahtik.com/blog/eclipse-word-wrap/ as current link points to a review which is great but misses some images etc. “Official” url is http://ahtik.com/blog/eclipse-word-wrap/ 🙂

    Ahti Kitsik

    July 28, 2009 at 14:52

  7. I fixed the link Ahti. Thanks for pointing out the error. Now just make sure you try e4. 😉

    McQ

    July 28, 2009 at 15:21

  8. […] From IDE to RCP to Runtime. From Platform to e4 (e.g., the future). […]

  9. […] developers? No Comments   by Lars Vogel / July 29th, 2009 Given the discussion about E4 and the evolution of Eclipse I’m wondering if it would make sense to introduce a […]

  10. […] lot of excitement around this project and I encourage everybody to get involved. First, please read McQ’s excellent overview, then read the whitepaper. Visit the e4 site. Most important, go and get it (though you may have to […]

  11. Thank you for taking the time to answer the concerned calls for more insight. I’m still digesting this, but I look forward to more insight like this from you and other e4 team members. It is a valuable resource for those of us who aren’t involved yet, even if we don’t necessarily agree with all of the assumptions and priorities, etc. At least we can’t claim ignorance.

    Eric Rizzo

    July 30, 2009 at 13:44

  12. […] Wilson’s blog post on the future of […]

  13. Due to my experience with developing Hyena [1] and Facetator [2], I am in the unique position of having used the following platforms: Dojo, GWT, Eclipse RCP, jQuery.

    I do share your excitement! I’ve also blogged extensively about the “perfect platform” [3]. A few comments:

    – You guys should talk to the GWT people as much as possible. They are doing incredible work, GWT version 2.0 is going to be amazing, also as a platform.

    – One big thing that GWT is missing and that Eclipse has (via OSGi) is true modularity. Very useful when collaborating with other people on a project. Some kind of client-side modularity mechanism plus server-side modules would result in a great platform.

    – Not enough standard widgets is another GWT problem. If GWT had the Eclipse community behind it, I’d suspect that that would quickly change.

    – More of my unfulfilled GWT wishes and a brief overview of 2.0 are posted at http://2ality.blogspot.com/2009/06/gwts-future-20-and-my-wishes.html

    – GUI layout for web apps is the thing that sucks most on that platform. Help is on the way [4], until then, drawing to Canvas (like Bespin does) is intriguing. Unfortunately, MS Internet Explorer does not support Canvas, yet.

    – While RAP is technically impressive, it is also complicated (e.g. one cannot start all the demos in different tabs at the same time) and slow. I would hope for a simpler and faster long-term solution.

    [1] http://hypergraphs.de/
    [2] http://hypergraphs.de/facetator/
    [3] http://2ality.blogspot.com/search/label/eclipse
    [4] http://2ality.blogspot.com/2009/07/css-layout-soon-good-enough-for-guis.html

    Axel

    August 4, 2009 at 11:23

  14. Is it too early to consider using e4 to develop an RCP application?

    I’m developing a Java application for my own use and it is in the mode where I add a new feature or fix a bug and then run the application a few times, then repeat the develop and run cycle. It will be in this mode for several months, at least.

    It’s getting to the point where I could use a GUI. I was considering Adobe Air and JavaFX since this is a desktop application that will eventually run on the web. I also thought about using RCP and adding Web Service connectivity when the app. moves from the desktop to the web. Since e4 is being built to accomodate applications that run on both desktop and web, maybe that would be a better way to go.

    Given that there is quite a learning curve with RCP, maybe I would be better off climbing the e4 RCP learning curve than the Eclipse Galileo RCP learning curve.

    Is this a viable thing to do in the near future (writing an e4 RCP GUI), or do I need to wait until e4 matures some more?

    Are there good resources available now to learn e4 RCP development?

    Thanks.

    Dean

    Dean

    August 4, 2009 at 12:32

  15. Dean, first a caveat, I work on E4 so I’m somewhat biased…

    I’d certainly check out E4 as a possibility; one of our main goals was to make E4’s learning curve shallower, you can tell us if we succeeded…;-). Get E4 0.9 and try out the e4Photo and Contacts demos to get a feel for what’s involved.

    Working with the 0.9 Tech Preview will have its challenges (i.e. the API’s aren’t fixed and -will- change over the next year…) but that’s a two way street. We’re extremely interested in getting ‘real’ feedback on our approaches so your input would be valuable to us and, indeed, will help drive the final design. This also means that you’ll likely get prompt attention to any snags you hit, after all we *want* you to succeed and we’re still at the point where we can address any architectural issues you might uncover.

    Eric

    August 5, 2009 at 10:00

  16. Cross-compiling SWT to Flex looks cool. How long until one can cross-compile to Dojo?

    Axel

    August 5, 2009 at 13:56

  17. Eric,

    Thanks for the response. It’s going to be a couple of months before I can undertake something like this. Hopefully there will be more learning resources for E4 RCP by that time.

    I’ll be back with more questions then.

    Dean

    August 7, 2009 at 10:56

  18. […] the title of the article. My understanding of e4 has evolved since I wrote the article. Based on McQ’s blog post, I better understand e4 as the incubator of ideas that it was meant to me and that, ultimately, […]

  19. […] Wilson’s blog post on the future of […]

  20. I think we should jump outside eclipse and see it from users’ perspective. For me, the key question to deal with is:
    – What are the benefices of using e4?

    Yves YANG

    February 4, 2010 at 11:29


Comments are closed.

%d bloggers like this: