BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Eclipse RAP 2.0 Released - Same Acronym, Different Name

Eclipse RAP 2.0 Released - Same Acronym, Different Name

This item in japanese

Bookmarks

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.

Originally created by Innoopract, now EclipseSource, the Eclipse Rich Application Platform was a re-implementation of the RCP, SWT and JFace libraries to build rich web applications. Instead of rendering to a native graphics device, the RAP implementation of SWT generated JavaScript, which was rendered in the browser using the qooxdoo widget library. State updates were synchronized between the server and the client using long polling HTTP requests. A similar concept is implemented by Vaadin, which uses GWT to provide JavaScript Widgets on top of a server side model, which is implemented using SWT inspired Vaadin components.

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.

With the release of 2.0 Eclipse RAP changed its name from Rich Ajax Platform to Remote Application Platform. The new name reflects the conceptual change to become a platform for any clients of a remote server, which already began with version 1.5, Ralf Sternberg from Eclipse Source writes in his RAP 2.0 blog series. While in 1.0 the server side component talked to its web browser counterpart via JavaScript, the communication is now using a public JSON API. With RAP 2.0 clients are no longer restricted to JavaScript, but can even be native implementations, like Tabris, which provides iOS and Android user interfaces.

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.

There are a RAP 2.0 New and Noteworthy and Migration Guide available, which should be read before attempting an upgrade

Fabian Lange is the author of the Eclipse Rich Ajax Platform 1.0 book.

Rate this Article

Adoption
Style

BT