Eclipse 4 Applications on RAP

Eclipse 4 is the new platform for application development in Eclipse. We already succeeded to run e4 applications on RAP two years ago, but then we got sidetracked by other efforts. Now that Eclipse 4.2 has become the primary development stream in Juno, it’s time to have another look at the topic. Last Friday I met with Lars Vogel, author of the first book on Eclipse 4, to find out how much effort it would be to run an E4 application on RAP.

One of the benefits of Eclipse 4 is that it decouples the application model from the actual rendering. With a workbench model that does not depend on SWT anymore, it should be possible to exchange only the SWT renderers and run it on RAP. Compared to porting the entire workbench, as we had to do for 3.x, creating an additional renderer for RAP should be simple. Our plan was to try exactly this. And before I get to the details, I can say that after just a few hours of work, our simple example application with a modelled workbench appeared in a browser :) So our plan actually worked out, even though there is much more to do for a real RAP support in E4.

For our experiment, we created copies of the o.e.e4 bundles that depend on SWT, changed the dependencies from SWT to RWT and adjusted some code that uses SWT API that is not supported in RAP – mostly uncritical code passages, which we simply disabled for this prototype. In a real implementation, we’d have to find suitable replacements. I found that there are still more tie-ins with SWT than I expected. Besides the SWT renderers bundle (o.e.e4.ui.workbench.renderers.swt), there is also an SWT-specific workbench bundle (o.e.e4.ui.workbench.swt) that contains a lot of model-related code. Another bundle called org.eclipse.e4.ui.bindings also has some dependencies to SWT, so we had to copy and adapt this one too. Finally, we disabled the CSS styling for now, which again incurred various dependencies to SWT. For me it seems that the separation of workbench model and widget toolkit can be improved, and this would help not only to provide RAP support in E4, but also to support other toolkits such as JavaFx. There are ideas towards this already so there’s hope.

Another advantage of Eclipse 4 over the old workbench is that global singletons have been replaced by dependency injection. These singletons have always been a problem for us, because different users need different instances, and we had to replace them with session singletons. However, even with these changes, the Eclipse 4 workbench is not yet capable of handling multiple user sessions. One known problem is that events are broadcast using the OSGi event admin service. In RAP all user sessions share a single instance of this service. However, I’ve learned that the event admin service is never accessed directly by E4 code, but always through an event broker interface in from the current context, which should make this problem much easier to fix.

Just out of curiosity, we’ve launched the same URL in a different browser to simulate a second user session. I was surprised to see the error message below. Without a core.resources bundle in the runtime there shouldn’t be a concept of a workspace, I thought.

It turns out that E4 treats the the OSGi data location as “workspace” and uses it to persist the model. But since the data location is shared among all users in RAP, this approach is another problem for multi user setups.

To sum up, it seems that there are still a couple of problems to tackle before E4 applications will run on RAP, but none of them seems impossible to solve. Now that we got the ball rolling again, I hope we can overcome these hurdles one by one. I won’t be able to put much time into this effort in the next months, but I’ll stay tuned and I’ll be happy to assist if someone is interested in carrying on these experiments, e.g. as a new component in the RAP Incubator project.

If you like to play around with our spike, the code is available on github. It’s based on the Juno version of e4.

Big thanks to Lars for his great help!