the corner office

So, what's Eclipse RCP like for building applications? My first observation is that client development is quite markedly different from web development. The difference manifests in a few ways - how you implement a true MVC pattern, how you interact with a data layer, the amount of coding you do to get bits together, the richer widget set, the more fine-grained interaction a user has with the application (not just submit-process-return like with web apps). Those are pros and cons, often at the same time. It's all just different.

I do have two gripes with SWT and JFace. First, while the APIs are powerful, they are also a little too powerful. Even with the bits of development I've done, I found myself whipping up all sorts of utility and wrapper classes to simplify the controls I was working with. The learning curve is steep, and while you can do a great deal more interface-wise, the downside is that there is often a lot of repetition and boilerplate code required to do simple things.

The second gripe is that JFace in particular tends to be a bit schizophrenic. Sometimes you can hard-code the links between parts of an interface, sometimes you use plug-in extension points to hook things together. Again, it's powerful and flexible, but harder to get to grips with.

I also think that JFace in particular is hampered by having a strong IDE heritage. One of the earliest issues I ran into was the distinction between editors and views. Can't mix 'em? Why not? The workbench is geared towards having a window with lots of little views and screen areas. What about good old-fashioned MDI? I know some MDI designs are butt-ugly, but a happier middle ground, perhaps?

One shortcoming that Eclipse has is the lack of a good visual editor. Netbeans' Matisse editor is highly regarded; you can get Matisse for Eclipse if you've got a MyEclipse pro license (I don't). I've never tried it, but it would be a welcome change from manually slinging controls into a GridLayout. Eclipse's Visual Editor project dwindled in the past year, never made it to the Europa release, and to date, it seems you still have to jump through some hoops to get it working. I haven't tried - to be honest, I can't be bothered with going to the trouble of getting it installed, only to possibly find that it's a sub-par tool that barely works and takes too long to master. Maybe that's not the case, and I'm sure it'll change, but I just don't think it's worth the investment in time right now.

As for plug-in development itself, I'm in two minds.

Plug-ins give you two things: modularity and extensibility. Extensibility is great - it allows you to write a plug-in and load it as part of your IDE. You can share your plug-ins with other users. You could provide different pieces of functionality to different users across an organisation. Etc etc. Plug-ins rock from that perspective (no pun intended).

In terms of just providing modularity... I'm not so sure. It makes sense when you have something as large and complicated as an IDE. When you're just throwing together a small desktop app? I don't know if the effort is worth it. Eclipse's ability to link plain old Java projects together is an incredibly powerful way to modularise your code, as it is. It's simple to use, intuitive, and it just works. Plug-ins are more complicated. Add a new package to a utility project, and you have to remember to export that package. You have to remember to add a new plug-in to your dependency list when you run our app. You have a whole new set of class-loading issues. You can't refer to JAR files elsewhere on your file system. You can't share icons and resources across bundles. Admittedly, these are mostly dev-time issues, which a good deployment system would mitigate. But it does make development more tedious.

Those are mostly the gripes, though. For all of the short-comings, it's been a refreshing change from the web model, and as I get more comfortable with it, I find myself becoming more productive. Rich and thick clients still beat web clients, in my books.

The coolest thing about Eclipse, though, is the fact that it's open-source. For the first time, I've truly understood the power of being to look on the other side of an API call, and see what's actually happening. Some of Eclipse's innards are truly complex and beyond the ken of mere mortals, but a great many other parts are basically just more Java code, virtually indistinguishable from what you're writing; the kind of stuff you see and maintain on a daily basis. Not only does this transparency help you to understand what you're doing and how best to use the tools, but it's also one of the fastest ways to improve your craft. What better way to get good at what you're doing, than to have easy access to a few million lines of code showing you how the pros do it?