Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
E4 summit debates on the future goals and directions of Eclipse
Posted by Alex Blewitt on May 28, 2008 06:00 AM
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?
RelatedVendorContent
Velociti Partners Customer Survey
Ensuring Code Quality in Multi-threaded Applications
Related Sponsor
The Adobe Flash Platform provides everything you need to develop applications, content and video across operating systems and devices.
Too slow
by
Daniele Bufarini
Posted
May 28, 2008 7:00 AM
Re: Too slow
by
Russell Leggett
Posted
May 28, 2008 8:14 AM
Re: Too slow
by
Daniele Bufarini
Posted
May 28, 2008 10:39 AM
Re: Too slow
by
Russell Leggett
Posted
May 28, 2008 10:03 PM
Firefox XUL
by
Ryan de Laplante
Posted
May 28, 2008 11:43 PM
Dot Com burt 2.0
by
L. Mihalkovic
Posted
Jun 4, 2008 6:58 AM
-
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...
-
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. -
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... -
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.
-
This demo shows an implementation that renders the UI using XUL:
http://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. -
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'?
6 comments
Watch Thread Reply