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 icon smile Eclipse 4 Applications on RAP So our plan actually worked out, even though there is much more to do for a real RAP support in E4.

E4onRAP Eclipse 4 Applications on RAP

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.

SecondSession Eclipse 4 Applications on RAP

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!

6 Responses to “Eclipse 4 Applications on RAP”

  1. Eric Moffatt says:

    Ralf, thanks a lot for taking the time to check this out. We are indeed looking at ways to move the current implementation away from its dependencies on SWT towards a more platform agnostic approach. We all think that this is a necessary step to move e4 into the wider UI arena of today…

    The ‘Workspace’ issue known (bug 330135) and will be addressed for SR2, feel free to comment on the defect if there’s something you’d like to see as a replacement.

    The eventing system is OSGI bound right now but as you say it’s relatively simple API-wise, do you have any suggestions as to how we could expose the functionality without the necessity of using OSGI ?

  2. Mark says:

    Looking forward to RAP and e4.

  3. Ralf Sternberg says:

    Hi Eric, good to hear that you have plans to further decouple model and UI. That will help a lot.

    For the event system, Tom already added a patch to bug 309868, but I didn’t try it yet. As soon as I have more insight about this issue, I will comment on this bug.

    Also the workspace issue seems to be less dramatic than I first thought. I’ve learned that the loading and saving of the model can be customized, so the problem left is just that the locking (bug 330135).

  4. Lars Vogel says:

    I would love to see 330135 solved. :-)

  5. Christian Schwarz says:

    I hope that CSS theming will be adjusted for RAP on e4, catchword “single sourcing” :-)

  6. Juergen says:

    As I recall RAP still lacks some widgets known in swt … rich text for example?!

6 responses so far

Written by . Published in Categories: Planet Eclipse

Author:
Published:
Jul 16th, 2012
Follow:

Twitter Google+ GitHub