The Road to Eclipse 4

This week, EclipseCon 2008 takes place at Santa Clara, California. Not all of us are fortunate to have the means or sponsors to participate. One of the interesting sessions will be an open discussion of the future of Eclipse 4, aka "e4". Since I won't be able to participate, here's some of my opinions on the future of the platform.

The Future of Desktop Apps and Eclipse

IMHO, Eclipse RCP today is probably the best framework for cross-platform desktop apps development. It's simple: if you want true cross-platform development, Java is your best bet. If you're writing a desktop app in Java, Eclipse is your best option for a decent UI. Almost every time I see a new cross-platform desktop application written in Java but not using Eclipse, my immediate reaction is "it's so ugly, why didn't they use Eclipse?". I've seen Eclipse RCP based applications which look so good that it's hard to tell that Java is behind the scenes (e.g. XMind).

There's a bigger question: what's the future of desktop apps?  I don't want to open the debate, but it is my opinion that they're not dead yet. Nevertheless, products like Microsoft Silverlight and Adobe AIR, are a big threat to Eclipse in this area. They provide the richness and ease of development of a desktop app with the deployment capabilities of an online app.

Consider this: you'll be able to use simple tools like Visual Basic to develop a rich desktop application and then deploy it over the web to your users and run it on multiple platforms. If Eclipse plans to stay in this game, this means that developing an Eclipse application should be as easy as developing a Visual Basic one. I'm talking about wizards, WYSIWYG editor, etc. It's possible that we will never get there, and that's fine. However, the focus should shift back from Eclipse as a Rich Client Platform to Eclipse as (the best) IDE.

Top Five Challenges for Eclipse 4

Performance - speed of execution, responsiveness of the platform and memory footprint. This has always been the Achilles Heal of Eclipse. It must be improved. I don't care how. Write a dedicated JVM optimized for Eclipse. Just make it work.

Easier Deployment - installation, automatic updates, plug-ins installation, configuration sharing between team members. It simply doesn't work well. No wonder there's a market for "Eclipse Distributions" like Genuitec Pulse. Take an application which works well with updates and add-ons, like Firefox, and follow its' model.

Cool UI - I want rich UI in my IDE. I want animations, fading elements and cover flow. As a plug-in developer, I want an arsenal that will enable me to quickly create an application that will dazzle my users. Spend some time on a Mac OS X and you'll quickly see my point.

Better Customization (for the end-user) - I want to change my toolbar, change my menus, record and edit scripts to automate repetitive tasks. I want these changes to apply to new workspaces that I open. I want to be able to share my scripts with teammates. Oh, I should be able to do that without reading a book about it.

Documentation - As a plugin developer, I often find myself struggling to get my hands on decent and up-to-date developer documentation. Code should not be allowed into production without proper documentation. This includes not only Javadoc, but also proper online help, tutorials and reference. Moreover, the information should be easily accessible from the IDE. I think about how easy it was to get this information in Visual Studio.  Follow this model.

This is from the top of my head. What's on your list?  the comments are open.

Comments

[Axel Rauschmayer]

Great post. My suggestions [1] are a bit more technical (and too long to post here).

[1] http://rauschma.blogspot.com/2008/03/eclipse-4-wishes-simplification-first.html

[Patrick]

About Silverlight and AIR, there is Eclipse RAP, which, basically, puts RCP on the web.

Been developping with it since last november, pretty impressive considering the age of the project.

[Zviki Cohen]

@Axel
Your post is very good, attacks some specific pain points. I can just say that I'm currently working on a tool which solves some of them. I cannot reveal much more at this point.

@Patrick
There are a number of ways of putting Eclipse on the web. RAP is one of them. I can refer you to a previous post I wrote about it. However, the fact remains that it is still much more complex than application development in Visual Studio or Adobe Dreamweaver CS3.
http://zvikico.typepad.com/problog/2007/10/eclipse-goes-on.html

[Axel Rauschmayer]

@Zviki Any kind of Google group or announcement mailing list one can subscribe to to be notified when your tool comes out?

[Zviki Cohen]

@Axel
This blog :-)

Here's some background (not a lot):
http://zvikico.typepad.com/problog/2007/06/some_informatio.html

[digital.alterego]

hm, sounds like qt jambi?

[Narayan]

1. Memory Management -- As someone who has spent two years developing MDSD tools using eclipse RCP, i think there needs to be significant improvement in memory usage and performance.
2. Documentation and API compatibility -- I can somehow manage without documentation, but issues with APIs that are completely missing in newer versions (especially GEF, EMF and GMF).
3. TPTP needs significant improvement.

[Bruno Eberhard]

If you are free in your specification of an application, eclipse RCP and swt/jface is ok. In the project developement world thats rarly the case. And then you almost every run into requirements that you simply cannot solve with SWT (try to set the forground color of a disabled Text for example). Call me old school but I still like Swing much more than SWT. I've done serveral years with both toolkits so I know what I am saying. SWT simply returns to write once test everywhere. And the complexity of RCP is huge. Every heard of the eclipse - classpath - hell if you have more than one plugin? Eclipse and RCP has done an execellent job in pushing sun to polish java. Thats the best part of it.

[Zviki Cohen]

I agree that SWT is far from being bug free and that there are platform "subtleties". Keep in mind that Eclipse is a community driven product. As plug-in developers, the least we can do to help is report bugs. You can also be proactive and join the effort to fix the bugs.

One word about Swing: UGLY!