Published by Fabian on 31 Aug 2007
Eclipse Rich Ajax Platform (RAP) – Proof of Concept
Today we concluded our one month evaluation of Eclipse RAP. I try not to disclose anything which I am not allowed to, but really want to share my experience.
RAP is quite a unusual AJAX framework. Actually it was created many years before the term AJAX was invented, but got speed in the recent years. It has a clear focus on web applications, rather than on webpages or sites, and it has one very interesting promise:
A Eclipse RAP application can run as is also in Eclipse RCP.
How can that work? Actually RAP is a reimplementation of SWT and JFace. The two APIs that you use to create standalone Java UIs. It also has a adoptet Eclipse RCP stack which provides a lot of services, including services to create windows and manage them as we know it from a typical IDE and the eclipse typical plugin and extension point concepts.
When you look at the RAP demo it looks a bit boring, it looks like a Eclipse running in a VMware or Citrix. The user experience is also not 100%good, it feels sometimes a bit sluggish. But that exactly is the promise (no that sluggishness not, they want to fix that
). The application shall behave and feel the same as a standalone Eclipse RCP would feel. And that goal is pretty much achieved. The only disturbing thing is, that I as a User Know that I am running in a web browser, so I get fooled a bit. Perception already improves when running the browser in full screen mode, which hides some bars that suggest you that you are running in web. But anyway, this is not a “iPhone-web2.0-gradient-roundcorner webtoolkit”, but targets clearly business use cases (at least for now).
In that context we did evaluate RAP, but with a important difference: We wanted to have the promise the other way around:
A Eclipse RCP application can run as is also in Eclipse RAP.
As we do have a Eclipse based standalone Java client this would be very good. But unfortunately this is not possible, due to some very plausible reasons:
- You have less control over the “window” your application is running in
- You have no local file system
- You have no very fast event loop, which eliminates e.g. MouseMove events
- You have different memory model.
- …
So what RAP decided to do is to implement a subset of the SWT and JFace API, as well of the Eclipse services. This keeps their original promise, but faces us with a challenge. We have to make our application running on RAP. So thats what we did:
- Get a workspace with very latest RAP CVS and load all UI plugins into it
- Create a Facade plugin
- Change dependencies from org.eclipse.ui.* to org.eclipse.rap.ui.* and add a dependency to the Facade plugin
- Compile
the result of this was a miles long error list. that is because of RAP having no empty implementations. What they do not support they do not have in the API. The RCP client we are talking about has all in all about 200k LOC. So that large number was pretty expected. But the first surprises came pretty soon. We discovered that there are large groups of problems which basically are all the same. Here is how the Facade Plugin comes into play:
- Locate all occurences of a certain compile error. Lets assume PlatformUI.getHelpSystem() [noSuchMethod]
- Create a Facade: PlatformUIHelper with a method getHelpSystem() and move the original code (here a single line into it)
- change all occurences to PlatformUIHelper.getHelpSystem() instead
The result is that a) the compile errors “move” to the Facade plugin and b) reduce from n-occurrences to only one.
After doing this for about 3 days, all compile errors were gone from our UI plugins. About 20 Helper and util classes have been created in the facade project. Unfortunately we are still unable to run the Application because there are still compile errors. But there is a simple solution for this. So in 10 Minutes, all compile errors were.. err… resolved…. Okay commented out
Everything compiling. Now the trial of fire. What will we see….
….
NullPointerException
But that was pretty likely. We changed a lot of code form returning something useful to return null.
In an iterative mode we created dummy implementations instead of null’s and passed them back. That was more successful and after a few tries we got to see our UI in a web browser. Powered by RAP. Wow.
We expected to see a lot ugly misplaced objects totally nonfunctional, but were heavily disappointed. It was really astonishing how much really worked out of the box. The UI looked a lot like the RCP one, just a few minor graphical mixups. Perspectives, views, context menus and all that fancy stuff was working.
Looking into details revealed some more issues. Partly our RCP code was using wrong API, and also code existed which was not actually following RCP design patterns. Of course also most stuff were we created dummy implementations for was not working right (but at least no throwing runtime exceptions).
We created a list with about 40 items. Those 40 items need to be resolved in one or the other way for the production version. But bugs we did only find one in RAP. We found some missing functionality and sent some patches (which were pretty fast included, thank you RAP team) and opened a few bugs in Bugzilla. Keeping in mind that RAP is still pre 1.0 release this is even more fascinating.
I never have dreamed that it is so easy to port a Eclipse application to RAP. The whole UI part is really working as promised. It was so good and convincing that people asked in demos about some decorative lines that were not where they should be, but totally forgot that we had absolutely nothing to implement to make the application to run in a web browser.
But of course there is work to do. The whole architecture was only designed to work in a different distributed scenario as it is in web. It could hog onto a desktop PCs memory. now we have to save some memory as the server will be shared. We have to revisit our thread implementations. We have to implement caches and make sure that singletons are changed (on a desktop you don’t care, you are alone in a JVM, on the server you are not and might share data you don’t want) . Still much work to be done. But this always would have been extra to creating a whole UI framework. That we do not need; that is provided by the RAP team.
RAP successfully passed our proof of concept! – Well done RAP! – Looking forward to your 1.0 release!
I am looking forward to our press release when we make the decision final
The bottom line for you, dear reader, if you made it that far, is that you really, really should consider RAP as first choice for doing web&desktop application based on a single sourcecode in java.