I’m working my way through the list of questions posed during the Eclipse RCP webinar.

One listener asked about a dozen questions (and I’m hoping to get to them all, really), including this one:

When talking about the user working offline with the intelligence in the application - where and how should the data be cached? What mechanism would you suggest for synchronisation and beyond that for handling resolutions?

Golly, that’s a tough one. For this one, I have to put my old consultant hat back on… the answer is “it depends”. Unfortuately, this really is the answer. It’s difficult to provide one single right answer for any situation, but there are several options you might consider (and which one is right depends on what kinds of things you need your application to do).

You could cache your application information in EMF-generated objects. Since EMF provides a pretty handy mechanism for writing out an object graph, this may indeed be a really good fit if your application is actually written to manipulate objects (and not just read and write gobs of data from a database). In this case, the model is pretty simple: you load your data from whatever data store you get data from into your EMF object model; your application can them merrily pound away on the objects (perhaps add, remove, or change a few of them) before either (a) writing them back to the data store, or (b) storing them in a file on the local disk. With this option, synchonization with the original data store is a matter of reconstructing the objects from the file (which EMF does for you) and then doing the necessary queries to write the data back.

Another possibility is to use a Java-based local database like Derby. You could write data that your client needs to the local database and access it from there using the same (or similar) mechanism that you use to access the main database. Synchronization is a matter of reading data from the local database and writing it back to the remote one. For this solution, I’m assuming that the RCP application directly accesses the remote database rather than working through an application server.

In both cases, knowing what actually needs to be written back to the original data store is an interesting challenge. In either case, you’ll probably need to have some mechanism for keeping track of what’s changed so you can optimize your writes. I don’t think that Derby has any ability to synchronize a local database with a remote one, but there may be other products out there that can do this sort of thing.

I like the EMF option for two big reasons. First, I like objects and I’m probably going to read my data into an object model anyway; EMF is a good way to represent an object model and provides all the functionality I need to store that object in a file. Second, with EMF, it’s pretty easy for me to develop a mechanism that can keep track of exactly what changes in my object model so I can know exactly what needs to be written back to my remote data store. I’m pretty sure that SDO may offer even more, but I haven’t had a chance to really look hard at SDO yet.

Of course, as I stated earlier, it all depends. The EMF route feels right when I need to retain a relatively small amount of data locally. I probably wouldn’t use it if I needed to have access to my entire database or a significant subset of it: in that case, I’d probably look harder for a good database replication story.

Our intrepid leader Mike recently asked me to build an example of how all this stuff might actually work. So keep your eyes on my blog… it’ll all be so very exciting.

I’m working my way through the list of questions posed during the Eclipse RCP webinar.

One listener asked:

What methodology do you propose people use?

This is an easy one: we don’t. I’m a huge fan of agile development methodologies (especially Extreme Programming) and so recommend that you at least look into them to see if they’re a good fit in your organization. At the end of the day, however, pretty much any software development methodology can be used to build Eclipse RCP applications.

Sorry about the lame joke, but my brain is also tired. I started my week in Antwerp, Belgium at the JavaPolis 2005 conference. I had a good time at the conference and am looking forward to attending again next year. I have to admit that I was expecting a lot more people to attend our events, but after reasoning/rationalizing through the fact that the conference actually started the day after our Eclipse in Action day, I guess we actually had a pretty good turn out.

I had a lot of fun delivering my presentation. The crowd sat in rapt attention (or was perhaps sleeping with their eyes open) as I delivered my spiel on Eclipse Rich Client Platform (RCP). I’m a little disappointed that the audience did not rush en mass to the stage, lift me up upon their shoulders and march me around the venue, but I guess you can’t get everything. At least not every time you deliver a talk…

After we wrapped up in Antwerp, we drove to Germany and visited a lot of people in a four-city marathon session. I have to admit that driving at 180 km/h on the Autobahn still makes me giggle like a little boy; though we did end up missing one meeting because of a pile-up.

One of the things we noticed during our visits is how little at least this small cross section of the world understand the open source development community. The short version of this story is that it is clear to me that at least some part of the Eclipse community doesn’t report bugs or request new features. Two of the companies we visited had constructed impressive applications using Eclipse RCP, with only a single bug report between them. They used my visit as an opportunity to pepper me with feature requests and bug reports, hoping that I would help to ease their pain (they had developed numerous work arounds). Apparently they had evolved a culture of not reporting bugs because the commercial vendors they use just ignore them.

It doesn’t work that way in Eclipse. Eclipse developers depend on receiving feedback though bug reports. If you use Eclipse, you should be creating bug reports when you find problems. If you don’t report them, how will they ever be identified and fixed? There’s a lot more to this story, but I’ll save the main discussion for another day…

The Eclipse Foundation is at JavaPolis in Antwerp, Belgium this week. Unfortunately, I haven’t been able to see very much of the conference outside of what we’re doing, because we’re pretty busy. We hosted a “Plug-in Bazaar” yesterday which was pretty cool. Many plug-in providers (for various products, including Eclipse) presented their wares to whomever they could attract to their table. While it went well, we did learn some lessons. Next year, we’ve recommended getting better signage for each of the plug-in since it was pretty hard to determine who was doing what (on the plus side, it gave me an opportunity to talk to people I probably wouldn’t have otherwise had an opportunity to talk with). Also, next year we’ve recommended that the bazaar be moved closer to the lecture theatres and the time be arranged around when the talks are in break.

Today, we’re doing an Eclipse IDE day (”Eclipse in Action”). So far, Dirk Baumer from the JDT team presented on the Eclipes Platform and JDT projects. Right now, I’m listening to Nuno Sebastiao from the European Space Agency (ESA) as he discusses the ESA’s use of Eclipse. Cool stuff.

I had a lot of questions during the webinar that I co-delivered a few days back, and I’d really like to answer them all. I’m going to do my best.

One of the listeners asked:

A lot of non-Java-savvy people still have the perception of Java as a slow language - they feel they’re giving up performance for more morally correct concepts such as platform independance, etc… What kind of real world performance are we seeing in the RCP (and specifically SWT widgets)?

The simple answer is that Java is quite fast enough for many applications and that Eclipse RCP applications are rather zippy in performance. In fact, there are a number of games implemented in Java (games being a type of application that tend to require pretty good performance). My kids are obsessed with RuneScape which is a massive online game written in Java. There are a great many other games also written in Java. But, I assume you’re not all that interested in games.

The Eclipse IDE is itself an RCP application and is a pretty good performer. For almost all of the RCP applications I’ve encountered, the performance of the application itself is great; it’s the backend systems (databases, web services, IIOP calls, etc.) that are normally the source of wait time. The SWT (Standard Widget Toolkit) that provides the Eclipse user interface components is implemented in terms of platform user interface components and is therefore pretty responsive.

Measuring performance is as much an art as it is a science. User perception is a key element and Eclipse has functionality to make the user’s perception of performance even better. If you’ve used the CVS repository exploring feature in Eclipse, you’ve probably noticed that it incrementally populates tables with information from the CVS repository as it is loaded. While the amount of time that it takes to get the data is the same, the fact that the list is at least partially populated and the GUI is still responsible makes the wait easier for the user. That same functionality is available for your applications (I use it in my eBay RCP application — which I’m going to try and make available soon).

At the end of the day, whether or not performance is good enough is a completely subjective discussion. In my experience, it’s plenty fast for the kinds of rich clients that most folks are building. Is it fast enough for writing games or applications that need to run a bajillion numeric calculations? Possibly.

Is a pickup truck “fast enough”? It all depends on what kinds of things you need to do with it.

Everytime somebody says something about the Eclipse 3.2 release train, I hear Natalie Merchant’s voice in the back of my head singing Peace Train. Is it just me?

I’ve been answering a bunch of questions from the webinar Jeff and I delivered a few days back.

One listener asked:

Do I need to develop three different applications if I want a Windoze, Linux and Mac version?

No. You can use exactly the same code base on all three platforms. You can “export” your application to all three platforms when you’re ready to deliver it to your users.

Here’s a screenshot of the last page of the Eclipse Product export wizard in Eclipse 3.2M3:

Before this will work, you’ll have to setup a target directory with the RCP delta pack. I actually started typing in the instructions for setting this up, but discovered quickly that it’s going to take a lot more time than I can reasonably spend on a blog posting. I’ve created Bug 120174 to recommend the construction of an appropriate tutorial for the Eclipse Articles site.

A recording Erich Gamma’s December 8th podcast is available for your listening enjoyment. As billed, the interview touches on the following points:

• Learn how to balance cost reduction against its impact on customer loyalty.
• What was IBM’s motivation in initially launching the Eclipse project?
• Where will Eclipse go from here?
• What are the challenges–and benefits–of Open Source software development?

I think that folks who are new to Eclipse can get a lot of value out of the talk. If you’ve been around for a while, there’s probably not as much in it for you (but it may still be worth a listen)…

Jeff and I got a lot of questions during the webinar we did last week, but we were only able to answer a few of them in the time we had available. The good people at BZ Media were nice enough to send me a file with all the questions. I’ve been spending a good chunk of my time trying to provide answers for all of them. And… I thought I’d share some of them.

One listener asked

Does Eclipse have a GUI builder that:

• Actually works and is good enough for everyday development,
• Is platform-independent, and
• Is open-source.

I’d like to build GUIs with SWT and JFace.

The answer is yes. There are actually many choices of GUI builders for Eclipse.

To start, there is the Visual Editor Project which you can incorporate into Eclipse using the update manager. The Visual Editor is quite good and I have used it for what I consider “everyday development”. It lets you build SWT and JFace components and it also does Swing and AWT. It provides reasonably good window building technology and you can’t beat the price.

There are other options as well (though some do go against the “open source” criterion). You might consider Jigloo which is free for non-commercial use or WindowBuilder which is a full-featured commercial product that now includes a handy perspective builder.

There may be others. There are a few sites that provide plug-in catalogues that can point you in the right direction…

There is a lot of talk about the Eclipse Rich Client Platform (RCP). Jeff McAffer and I delivered a webinar on the topic a few days ago and I’m getting ready to deliver a similar talk at Javapolis in Belgium next week. One of the things that I like to include in a talk is a definition of “Rich Client”.

Wikipedia does a terrible job of defining Rich Client. In fact, it just redirects you to Fat Client, which I think this is wrong. In many ways, a rich client is very similar to a fat client: both provide a rich user experience using time-honoured user-interface components with great graphical features, drag and drop and the like. Both run interesting behaviour on the client workstation (contrast with the browser which tends to run view rendering and minor application-specific logic on the workstation). Both rich clients and fat clients have an implied server component (though this is not necessarily the case as it is possible to build completely standalone applications with both).

Perhaps one of the bigger differences, at least at some conceptual level, is that rich clients tend to leverage relatively interesting backend resources like an application server; fat clients tend to connect directly to databases. Of course, this is not necessarily the case, as it is completely possible and totally reasonable to build a rich client that connects directly to a database. It is also the case that many fat clients do access more interesting backend resources.

For those of you who like to see pictures, here’s what a fat client might look like:

And here’s a rich client:

I don’t know that it’s a particularly good graphic, but the basic idea is that some of the control and business logic for the application is shared between the rich client and the application server. As a general rule, I tend to try and hide the database access behind the application server, but that’s a discussion for another day.

But the differences are bigger than the nature of the server. In my opinon, a rich client:

Delivers a rich user experience. This is obvious.

Is typically a client for some backend service. Again, this is pretty obvious

Is platform independent. In the salad days of client-server development–when fat clients were all the rage–we had pretty tight control over the delivery platform. That’s just not the case anymore. Even within relatively small organizations, it is not uncommon to see multiple platforms (Windows, Mac, Linux, …). Being able to support these multiple platforms using native look and feel (looks and acts like a “Mac” application on the Mac, etc.) is pretty important. Very often, the rich client is an integration point and so must be able to leverage platform component services and such as well.

Runs with little or no modification on multiple platforms and devices. This is related to the previous point, but with a hook: devices. More and more of our work is being done on relatively small devices like PDAs and phones. Even if you’re not doing this today, you’ll likely be doing in some time in the future. Development resources are pretty expensive, so being able to move existing applications to new platforms relatively easily is critical.

Has robust component model. We built components in those previously-mentioned salad days, but we did through architecture of the application. An explicit component model framework is absolutely critical when it comes to building rich clients. Applications today are simply too complex and integrate too many different technologies from too many different groups to not have a sophisticated framework for managing dependencies and communication between components.

Has an integrated update mechanism. One of the biggest challenges with fat client applications is keeping them up-to-date (just deploying them is pretty hard). Rich client applications must be able to update themselves easily.

Must be extensible. Change is an important force in software development that cannot be overlooked. A rich client application must be able to accommodate change. We must be able to easily change the behaviour or add new and completely unanticipated behavior. This, of course, relates to the need for an update mechanism, as we need to have a way to deliver this new functionality.

Has the potential to work offline. We’re almost to the point where we’re always connected. Maybe in another ten years or so, it will be difficult to find a place where we’re not. However, in the meantime, reality is that many of us need to be able to work disconnected from a server.

Since I’m often accused of being a little long winded, I have opted to keep my discussion of each of these points short. I’ll try to build on some of these over the next few days and weeks.