Three Runtimes

I’ve been spending a great deal of time working with Eclipse runtime technology recently. Specifically, I’ve been building an example application that deploys using Eclipse Rich Client Platform (RCP), Rich Ajax Platform (RAP), and embedded Rich Client Platform (eRCP). The application itself is simple enough: I like examples to be as simple as possible, but useful, so I built an expense tracker. I figure that, if I can make it useful enough for my purposes (i.e. help me keep track of my travel expenses and automatically fill out those forms I hate love so much), it will give me great motivation to keep it up-to-date and new versions of the technology becomes available.

I started first with an RCP version of the application. I’ve been building applications using RCP for a while, so this seemed like a natural enough step.

After I got some bits of the functionality working, I switched over to RAP. The switch to the technology itself was pretty straightforward. I installed the development plug-ins from the update site (they provide some handy launchers that make testing super easy), and downloaded and unpacked the runtime target platform. RAP applications, just like RCP applications require a target platform which provides a set of bundles that form the foundation of the application. The cool thing about RAP is that it lets you build applications using almost exactly the same set of APIs that you use when building RCP applications. In the ideal case, you switch from an RCP target to an RAP target and you’re in business.

While RAP provides a growing subset of the the same APIs made available to RCP developers, they are packaged differently. In my original work, I had specified a number of bundle dependencies. Since the names and organization of the bundles in RAP are, in some cases, different than those of RCP, many of the dependencies could not be found (package and class names are the same). I switched from using bundle dependencies (Require-Bundle) to using package imports (Import-Package). I’m not sure if there is a recommended practice in this domain yet, but I opted to use package imports for all “system” dependencies, and bundle references for dependencies on other bundles I created.

The conversion of the application from RCP to RAP was pretty quick and relatively painless. With this success in hand, I turned my attention to eRCP.

The conversion to eRCP required a bit more work. First, I had made the cardinal sin of using Java 5 (language syntax and libraries). Most of the migration effort to eRCP was a pretty mechanical process of converting to the version of Java supported on the device. Specifically, I had to convert everything down to Java 1.3 and CDC-1.1/Foundation-1.1 libraries. This required more than just changing syntax as I had used some APIs not included in the target environment; this sent me searching for replacements for functionality such as regular expression parsing. Once I worked out my addictions to Java 5, I turned my attention to the user experience. Before I started down this path, I knew that eRCP didn’t have a notion of perspectives (tiny screens don’t lend themselves to perspectives), I tried to carefully design the various views in my application to work with this restriction.

My initial effort has resulted in an application that runs on all three platforms. Some 90% of the code is exactly the same on all platforms. In fact, I have a handful (recall that I wanted to have a relatively small application) of bundles that are just shared and so are immediately testable and deployable on the various platforms.

I have an “application” bundle for each platform that pulls all the parts together in different ways. The RAP version of the application presents itself in full screen (full browser?); the RCP version uses the Nebula CDateTime widget, the eRCP version adds explicit navigation between views and leverages the special “command” buttons available on a device. I can envision other “application” bundles that assemble and manage the components for different types of devices; the way that I interact on an iPhone (at least theoretically) is different than I do on the Nokia E90 I’ve been playing with; I can capture the different navigation aspects in a separate bundle while still leveraging the 90% functionality reuse.

I intend to talk more about this application over the next few days and weeks (and post some pictures). When I get home from from JavaOne this week, I’ll start the process of contributing this application to the new Eclipse Examples Project. In the meantime, I’ll be at the Eclipse booth at JavaOne. Find me there (or at the Thirsty Bear on Wednesday night).

This entry was posted in Examples. Bookmark the permalink.

5 Responses to Three Runtimes

  1. Pingback: Eclipse hints, tips, and random musings » Blog Archive » JavaOne: Do Not Enter

  2. Neil Bartlett says:

    Wayne, with regard to your question about Require-Bundle versus Import-Package… yes, there certainly is a recommended practice in this domain. It goes as follows:

    ALWAYS use Import-Package. NEVER use Require-Bundle.

    Nice and simple, I’m sure you’ll agree😉

    Section 3.13.3 of the OSGi specification details some of the things that can bite you on the bottom when using R-B, but it doesn’t go into what I think is the really important point: the ability to refactor. Often during bundle development you notice that some functionality doesn’t really belong in the bundle it’s currently a part of, so you want to either move it to another bundle or pull it out into a whole new bundle. So you move the packages around, and then all the bundles that were using R-B to get that functionality immediately break. But all the bundles that were getting it with Import-Package just continue to work, without any changes.

    Require-Bundle binds you to an arbitrary wrapper around the functionality you want, rather than to the functionality itself. This is why moving to Import-Package helped when porting from RCP to RAP: in your code, you want the org.eclipse.swt package (amongst others), you don’t care whether it comes from the bundle “org.eclipse.swt” or the bundle “org.eclipse.rap.rwt”. If that is useful for the “system” bundles, why not your own bundles?

  3. Hi Wayne,

    Chris recently blogged about a similar RCP-RAP-eRCP sample project (Tic Tac Toe) and also mentioned to contribute it to EEP. Maybe you should merge your stuff in order to keep EEP from exploding …

    Heiko

  4. Yes Heiko, the plan is for me to contribute my example to EEP also. There’s nothing wrong with multiple examples, I’m pretty familiar with Wayne’s example and it’s a bit more complex than mine. I like to always have things as simple as possible first. Once people get familiar with the TTT example, I’m sure people can go to Wayne’s example to further grow their knowledge (as his example has more advanced use cases than mine).

  5. Pingback: Eclipse hints, tips, and random musings » Blog Archive » Introducing EBERT

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s