I blogged last week about an example application that I’ve been building. Building good examples is pretty hard: you want an example to be simple enough to understand. At the same time, it has to be real enough to useful and expose real issues. I think that this application strikes a reasonable balance. The Eclipse Business Expense Reporting and Tracking (EBERT) application is a relatively small, but provides a valuable service. At least as a business traveler who has to work with Excel-based expense forms, it’s valuable to me.

Here’s a snapshot of the RCP version of EBERT:

Here’s what it looks like in RAP:

Note that the RAP version is running in a browser embedded in an Eclipse editor. It also runs fine in a regular browser like Firefox.

Here’s what it looks like in eRCP running on a Nokia E90:

You’ll notice some similarities and some differences. The really cool part is that some 90% of the code (estimate) is exactly the same across platforms. That 90%—the exact same code without recompiling, repackaging, or manipulation of any sort—is deployed on the desktop, the server, and a phone. This is one of the great things about Equinox and the various runtime platforms at Eclipse: the exact same component model, Equinox, is used everywhere.

Here’s a high-level architecture of what’s going on:

The common bundles—those in the middle—contain most of the interesting behaviour. Specifically, these two bundles contain the basic business models (core), and the various views and custom widgets (ui). Underneath these common components are the various runtime platforms which all themselves sit on Equinox (actually, the E90 uses Prosyst’s implementation of OSGi).

At the top are the various “application” bundles. Each of these bundles pulls the pieces together for one of the platforms. The “application” bundles provide some customization of the views, and—in the case of the eRCP version—some navigation glue that manages the views in the absence of perspectives (which are not supported on eRCP due to screen space limitations).

Yesterday, I (finally) submitted it to the Eclipse IP review process as the initial contribution for the Eclipse Examples project (CQ 2310). There’s still a lot of work to do (the application doesn’t quite live up to the Examples project’s values yet), but we should hopefully soon have some code where you can find it, look at it, and maybe contribute.

The Eclipse booth at JavaOne is being hosted this year (as it is normally hosted) by a broad cast of Eclipse committers, representatives from member companies, and other generally-knowledgeable people.

Yesterday, some of the folks from nexB hung out at the booth, answering questions about Equinox and being all-around great ambassadors for Eclipse. Here are the nexB folks (along with Lynn and Donald) during a lull in the excitement (it’s hard for me to take shots when there’s lots of activity at the booth, as I end up being one of the folks chatting with the visitors).

A highlight of the show for me was meeting up with Luke Li, and old friend from university (back then we knew him as Danny Li). Here’s Luke eating the fish after a great Sushi dinner.

Hanging out with the nexB guys, and then later with Doug and Shaun from EclipseLink and Virgil from BIRT is the best part of the show for me.

Today, be sure to drop by the Eclipse booth. I’ll be there from 1130 to 1330 to chat about Equinox, runtimes, and everything else you want to know about Eclipse. Mik Kersten will be there from 1330 to 1500 to talk about Mylyn, and Oliver Wolf will be there from 1500 to 1630 to talk about Swordfish. FWIW, no real swordfish were injured during our sushi-fest last night…

JavaOne is not what you might call my favourite show. This sign about sums it up for me.

How welcoming is that? It’s “Java + You”, but “Do Not Enter”. Let the lovefest begin. Did I mention the beanbag chairs?

The keynote this morning was uninspiring. With Java FX we can make lots of fancy graphics with animated flames and stuff. How cool is that? And now… Neil Young. Frankly, I what was not said speaks louder than anything that actually was said.

Mike and I did a talk today titled “The Many Moons of Eclipse”. The talk was well-received. Mike has been doing a talk like this for years. Two years ago, the audience asked for more code. Last year they asked for a demo. This year, we tried to give them both. I demoed an application that I’ve been writing running on eRCP on a Nokia E90, and RAP and RCP on Ubuntu Linux. This is the same application that I spoke about yesterday. Here’s a screenshot of the RAP version:

RAP totally rocks. I feel great pity for anybody who doesn’t know about RAP (and will be taking some steps over the next week or so to resolve that problem).

After our talk, I spent a few hours in the exhibit hall at the Eclipse booth chatting with people about various Eclipsey things. This is the shining light for me at JavaOne: interacting with people who are as excited about Eclipse technology as I am (and I’m pretty excited about it). I spoke with a couple of folks from Quest about some first-class integration they’ve done between Eclipse and JProbe. I’m looking forward to getting some trial software for review. I’ve spoken with dozens of other folks who are building their businesses based around Eclipse technology.

Mike and I walked past James Gosling and Jonathan Schwartz today. Jonathan gave Mike a curt nod. I’m sure it was very exciting for him (Jonathan that is; Mike seemed indifferent)…

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).