As part of the upcoming Eclipse Ganymede release which is scheduled for June 25th, InfoQ will cover a series of Eclipse subprojects. Today, the subproject is RAP (Rich Ajax Platform), which is releasing version 1.1. InfoQ spoke with Jochen Krause to learn more about RAP and what it provides.
In describing the capabilities that RAP brings to Eclipse, Krause first divided the Eclipse user base into two parts - those who use the Eclipse IDE and tooling for development, and those who use Eclipse Platform-based applications. Krause said that for IDE/tooling users only the RAP tooling itself would be exposed, so they will not see RAP functionality in their development tools. However, users of Eclipse Platform-based applications will now have the ability to build rich, AJAX-enabled web applications using the Eclipse OSGi-based Plugin development model, JFace and a web-enabled version of SWT. RAP is intended to be very similar to the Eclipse Rich Client Project (RCP), with the major differences being a reduced API and some allowances for the multi-user nature of web applications. Compared to RAP 1.0, 1.1 extends the API to include new features such as MouseEvents for SWT, ImageDecorators for JFace and several wrkbench enhancements -- it also incorporates new Eclipse 3.4 capabilities such as enhanced security and alpha-shading for widgets.
when asked how RAP fits in alongside other AJAX frameworks such as Dojo, GWT and OpenLaszlo, Krause said:
RAP is a AJAX framework with a server-side focus and a strong tie into OSGi, Equinox and the Eclipse Platform. It is not easy to compare RAP to the other frameworks because the focus is different. Dojo, GWT and OpenLazlo do a great job with their widget toolkits, but do not have a broad application platform to offer. We do not see those frameworks as competition, in contrast they may become additional options for the client side rendering in future RAP version. Today, the client side rending for RAP is based on qooxdoo, also a powerful AJAX framework. RAP and GWT both enable developers to code in Java, but the runtime model is quite different. GWT is executed entirely in the browser, RAP execution is split between server and browser.
Krause also spoke about the RAP ability to compile a single codebase to either an AJAX or an RCP application, saying that it wasn't as complicated as it might first seem. Compilation is done against the same Workbench, JFace and SWT APIs, but when running as a web application web-enabled versions of these libraries are substituted for the usual ones. At runtime, the application code is run primarily on the server, with a JavaScript-based UI that sends events to the server and sends back results to the client. However, Krause did point out three things that RAP developers need to keep in mind:
- The web is a multiunser environment, so holding application state in static objects such as singletons is likely to cause issues
- RAP currently provides a subset of RCP - if extra RCP capabilities are desired beyond those that RAP supports, the recommended way to include them is via plugins
- Because applications are executed on the server, developers should not allocate large amounts of memory per user (this is a good best practice for desktop apps as well)
As part of the next-generation version of SWT, RAP plans to provide a fully AJAX-based implementation of SWT. Krause pointed out that not every platform supports all of the SWT APIs, and that SWT was designed for desktop applications. Although most of the SWT API can be implemented, some things such as drawing on the canvas or detection of mouse movement will have to await further browser enhancements in these areas. Other currently-absent APIS such as drag-and-drop and key listeners are planned for the next RAP release, with technologies from other teams such as SWT's Java/Flex cross-compiler being used for complex components such as the StyledText widget.
With respect to future plans for RAP, Krause indicated that there are two main areas of focus: Extending the RAP APIs to implement more of the RCP API, and providing a user experience which utilizes the Eclipse platform and also feels natural from a web perspective. Krause expanded upon the second idea, explaining that RAP is addressing the usability challenge by working with usability experts and analyzing user interactions. Krause also saw the convergence of web and desktop applications through AJAX and RIAs as another area of interest, and said that research has indicated that it is feasible to provide graphical editors based on the Eclipse Draw2D API in a web environment.
When asked how RAP would be integrated into or affected by e4, Krause said:
Running an IDE in a browser is a use case that does not have a big appeal to me. JDT does a great job on my computer and I think most developers feel the same way. That does not mean that there are no use cases where web technology comes in handy. Just look at requirements, task management or development process management. Those are areas where I see RAP playing a role in the future. But back to the question. The Eclipse platform team and the RAP team have jointly announced e4 at EclipseCon 2008 and both teams will start working on this platform right after the Ganymede release. RAP will be in the technology mix to web-enable applications, but it will not be the only possibility to do so. We also want to enable other web / JavaScript technologies to attach to the Eclipse platform. I expect a lot of cross fertilization happening. The RAP team can provide implementations and know how around multi-user enabling the platform, the SWT team has researched cross compiling widgets for RIA platforms like Flex / Silverlight. Better styling is another focus area of our joint work. There are so many more things to talk about, but e4 probably warrants an interview in its own right.