BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News E4 summit debates on the future goals and directions of Eclipse

E4 summit debates on the future goals and directions of Eclipse

This item in japanese

Bookmarks

With only a few weeks to go until Ganymede is released, already the sights are set on the future of Eclipse, referred to as E4. A recent E4 Summit debated the future goals and directions of where Eclipse is going in the future. InfoQ previously covered the scope of E4, but now it's starting to get more concrete. At this point, the E4 name is more of a code-name than a planned version number; and Eclipse 3.4 may be succeeded by 3.5 next year before E4 makes an appearance.

The main work item is to enable the Eclipse environment to run in a web browser rather than (necessarily) as a standalone application. Although RAP (webinar) has shown how it's possible to get a web-based rendering of a server-side Eclipse application (demo of workbench, demo of mail), the majority of the existing Eclipse workbench and IDE plugins are built to assume a specific hard-coding to the user interface.

There's an ongoing discussion on the future of SWT with the SWT Browser Edition. The current implementation of RAP uses the Qooxdoo AJAX library (demo) to render the UI remotely from the server. That might be a valid approach, or alternatively a cross-compilation technique like GWT might be used, although the underlying target might be a different in-browser VM (like Flex or Silverlight).

Another direction is to allow other languages to be used to write plug-ins, potentially allowing for scripting Eclipse in the future. Scala has been suggested as a language, although it's likely that some form of dynamic language like JavaScript or even JRuby will also be supported.

In order to permit the UI to be rendered in a web-browser with server-side storage, work has to be done to de-couple some of the singletons that assume a one-to-one user-to-workbench relationship. In addition, some of the synchronous APIs (like EFS) need to be migrated towards an asynchronous communications channel to deal with the inherent asynchronous nature of web-based systems. A new resource model is being discussed, hopefully avoiding some of the restrictions (like non-nested project hierarchies) that are built in to the current API, as well as a new application model.

There's been a lot of progress, not the least of which is that the E4 development process is a lot more open than before. However, bear in mind that this is all experimental; so there's no specific rules about what E4 should (or shouldn't) look like. There are some demos available if you want to download and try out the prototype code so far.

What do you think of the evolution from client-side IDE to web-based framework?

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Too slow

    by Daniele Bufarini,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    IMHO, running the Eclipse environment in a web browser is a nice idea, but not a practical one: the demo of workbench (see the link in the article) clearly shows that it's too slow be of any usefulness. I think that with the existing technologies, only applications designed with the web in mind - like gmail or google maps - are going to succeed...

  • Re: Too slow

    by Russell Leggett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Depends on the technology they use. Right now, Ajax is not super fast (though I think we'll be seeing improvements soon), but there are other technologies.

    alternatively a cross-compilation technique like GWT might be used, although the underlying target might be a different in-browser VM (like Flex or Silverlight).

    Technically, they could still do it in Java, even JavaFX, using the new applets. But Flex has shown itself to be pretty capable of a desktop like experience - especially if a lot of the real work is being done on the server.

  • Re: Too slow

    by Daniele Bufarini,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Technically, they could still do it in Java, even JavaFX, using the new applets. But Flex has shown itself to be pretty capable of a desktop like experience - especially if a lot of the real work is being done on the server.


    Yes, I might agree with you, except that... I have still to see a usable complex user interface - like the one of eclipse - done in Flex or JavaFX or whatever existing technology.
    Even if the real work is being done on the server, you have to move data back and forth between the client and the server. In my experience you cannot design a web application as if it a desktop one, even if all your frameworks abstract you from the fact that your application is running on the web...

  • Re: Too slow

    by Russell Leggett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I've never built an IDE, so I can't speak for everything, but in terms of complex ui, JavaFX and Flex are more than capable. JavaFX just leverages Swing and Java 2d apis. And while Eclipse is built using SWT, Swing is more than capable. I know that the Java plugin has been terrible in past, but it really does look like there has been a lot of effort to improve it and I think within a couple of years the whole RIA landscape will have stepped up a bar. As for data transfer, I think that could be minimized, but I would also point out that Flash and Java can open up sockets instead of using standard HTTP requests, and therefore can have much better data exchange performance.

  • Firefox XUL

    by Ryan de Laplante,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This demo shows an implementation that renders the UI using XUL:



    www.alphaworks.ibm.com/demo/flash/display/eclifox0



    I don't understand why they wouldn't just use applets and swing (possibly including JavaFX script). By the time a web based Eclipse RCP is available the new super fast applet plugin will be publicly available. The only reason I can think of to tie Eclipse RCP to Firefox and not use Swing is because it would be admitting that Swing has caught up to SWT.

  • Dot Com burt 2.0

    by L. Mihalkovic,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Aside from any technical aspects of this idea, reading the announcement that the future of Eclipse is the browser reminds me of the dot com burst 1.0, when the general thought was that if you couldn't devise a better plan all you had to do was "make it web enabled" and watch your company valuation take off.

    When everyone seems focussed on 'how', I ask 'why'?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT