Eclipse RAP 2.0 Released - Same Acronym, Different Name
On January 11th, Eclipse RAP 2.0 was released, after 6 years of development. During that time the project has been fully integrated into the Eclipse Platform, to support multiple user interfaces on top of Eclipse 4.
Some limitations of RCP however, were impossible to overcome in RAP 1.0. Eclipse RCP for example was not designed to deal with more than one user, which is completely normal for a web application. During the development of Eclipse 4, these limitations were corrected, allowing RAP to provide a universal API for any kind of client implementations.
InfoQ asked Ralf Sternberg, project lead of Eclipse RAP, about the next plans for the project:
InfoQ: Congratulations on the 2.0 release. It is great to see many issues RAP 1.0 had resolved by the combined progress made by the Eclipse Platform and RAP Teams. What were the biggest issues you solved, and how was the cooperation?
Thank you! Looking back to the 1.0 days, RAP has been a cool newcomer project that was somehow able to run an RCP application in a web browser. Over the years, the project has matured and is now an integral part of the Eclipse universe. This allowed us to raise awareness of the challenges of server-side applications in the Eclipse community.
The most obvious of these challenges is dealing with multiple users. To give an example, storing a single fixed translation of a string is no longer sufficient when users with different languages access an application simultaneously. The multi-user requirements of RAP eventually lead to the multi-locale support in Equinox and also some adjustments in the JFace dialog framework.
Looking at the Eclipse platform today it is nice to see that server-side requirements have influenced the design of the new Eclipse platform, E4. Server-side applications generally require more attention to decoupling, thread safety and performance. As technology develops, I think that those practices will become standard for every modern application.
InfoQ: For what type of projects do you think is RAP suited best? How did that improve with 2.0?
Currently developers are facing an increasing set of relevant target platforms that applications are required to support. Five years ago the relevant platforms have been desktop and browser. Today, mobile phones and tablets are taking over. Each platform requires different development tools and specialized know-how. That is exactly the same problem we tackled with our idea of single-sourcing applications for different platforms.
With RAP 2.0, we introduced the option to connect clients for any relevant computing platform based on an open protocol. At EclipseSource we offer native clients for iOS and Android under the "Tabris" brand. And the new protocol allows anyone to develop RAP clients for other platforms. With these developments, RAP continues to provide a "write once, run anywhere" platform.
Consequently, RAP is best suited for projects that are looking for a sustainable development model that includes the option to reuse code even on future platforms. This demand is most common in the enterprise space.
InfoQ: What are the next steps for the future? Are you looking at what similar technologies like Vaadin are doing? Where do you want to position RAP?
Of course, we are watching other projects in the serverside UI space. There are some really impressive frameworks for single-page apps out there, and we are using them as a benchmark to improve the look and feel of RAP. We are still seeing some room for improvement and together with our user base we are addressing them step by step. An example of late is a new dynamic dropdown for the Allianz insurance.
In the near future I would like to see a wider range of custom widgets for the WebClient. RAP 2.0 offers a simple client-side API that makes developing custom widgets and add-ons easy. Add-ons can now use any JS library and do not depend on RAP internals anymore. This extensibility is an important asset for us and we will continue improving this.
However, what sets RAP apart from other frameworks is that it can go beyond HTML5. To my knowledge RAP is the only cross-platform single-sourcing framework that allows developing an application once and accessing it with different runtime platforms. Browsers are one option; native apps using native widgets, native look and feel, and native navigation concepts are the other, rather powerful option.
Another key feature of RAP is its support for building modular applications. RAP is built on OSGi and as an Eclipse project it integrates naturally with Eclipse technology such as EMF, EclipseLink, or the Eclipse Databinding. Using JFace makes it easy to connect a UI to a data model. We believe that modularity is key for modern applications.
InfoQ: Any advice you want to give developers for upgrading their projects?
You should be aware that RAP 2.0 is not binary compatible to 1.x because we used the opportunity of a major release to consolidate some of our API. Nevertheless, I would recommend upgrading soon since RAP 2.0 has some significant improvements such as an improved new event handling system and a revised server push system. I've seen a couple of projects now doing the migration quickly and without problems. We provide a migration guide on our web page to assist projects with the upgrade.
Fabian Lange is the author of the Eclipse Rich Ajax Platform 1.0 book.