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?

August is drawing to a close, and the end of August was the deadline I had given myself for tinkering with Eclipse RCP. It's taken longer than I'd expected - being a new parent means coming to terms with a little less 'me-time' - but it has started coming together. I'm by no means well-versed, but I find myself feeling a lot less confused and frustrated than I was back in April and May and June. So I'm not quite sure whether I'll be packing it in just yet.

My motivation for getting to grips with Eclipse was mainly due to me not wanting to resort to web development every time I wanted to whip up a new application at home. Swing was an alternative, but since Eclipse has been my primary IDE for a good few years now, I figured it'd be quite useful to actually get under the hood a bit. My initial goal had been to get to grips with the basics of Eclipse RCP development, finish off one application which I could bang up on my site as a nice 'deliverable' and then move on to something else.

The main pet project I've been tinkering on has been a simple budgeting application, as I've mentioned before. While it's turning out to be pretty useful (living with another currency took some adjusting), and I keep adding new features, it's fairly specific to our own needs and nowhere near being in any state for sharing. Chances are, it never will be, and I'm not sure that the effort required to make it usable to anyone else is worthwhile. As for 'deliverables', I have been jotting down a few notes about how to go about doing things in an ever-growing page on this site, and a fair number of interesting things make it onto my link blog. That will have to do.

Next: reflections on Eclipse RCP development.

I think there should be a law banning the media from referring to child victims by their first names in headlines. Every few months when something bad happens to a child, it's all first names and sensationalist feigned outrage while the news presenters and journos and editors and managers are going home at night and thanking God that bad shit keeps happening and driving up their ratings. It's a piss-poor and blatantly cynical attempt to tug at heart-strings and provoke a more emotive response from viewers and readers. Rhys? Rhys who? The poor kid had a surname, assholes, and you vultures never knew or cared who the fuck he was until he got shot. Show some respect.

That is all I have to say.

I haven't run into it too often in the past, because I'm normally not too big on nested classes, but since I've been playing with Eclipse RCP and doing GUI stuff, it comes up all the time. I'm talking about the Eclipse compiler warning that gives you this:

Read access to enclosing field Foo.bar is emulated by a synthetic accessor method. Increasing its visibility will improve your performance

It happens when you're accessing a private instance variable of an outer class, from within a nested class. Oer. Performance affecting... can't have that. I'm firmly in the 'fix all compiler warnings' camp, and if my Problems view isn't empty, warnings or otherwise, then I'm not happy. I wasn't really liking the sorts of workarounds needed to silence the warning though, and I wondered how bad it could be, so I decided to do some homework.

There are a great many references to the problem, but the two most enlightening discussions are one from the ADVANCED-JAVA mailing list archives, and one from the Eclipse jdt-dev newsgroup.

Since the referenced variable is actually private, and since nested classes are actually compiled to be separate classes, there's no way for the nested class to directly access the variable. Eclipse is warning you that the compiler has to work around the visibility problem by creating a synthetic accessor (ie. add a getter method) to the outer class, which the nested class then calls.

... and that's all it is. An extra method call is needed to reference the instance variable, and since method calls are more expensive than directly accessing a field, not having the accessor method will 'improve your performance'. OK technically true, but this isn't 1970 anymore, so a method call is somewhat unlikely to be high on your list of things to worry about when it comes to performance. In other words, pffffff.

There is one other potential issue: this special accessor method, albeit obscurely named, means that the private variable is no longer truly private. Yet again, in most, as in most to the power of a bazillion cases, it's simply not an issue.

In other words, the 'synthetic accessor' warning is now one of the handful of Eclipse compiler warnings that I disable and don't feel guilty about.

This is one of those 'I fixed a problem but I'll be damned if I can do it again' posts. I wanted to get my favouritist monospaced font for Linux, Schumacher Clean. It's installed by default on Ubuntu, to a bunch of /usr/share/fonts/X11/misc/clR*.pcf.gz files. Linux and X and fonts is a world I've always remained gleefully ignorant of, probably to my own detriment a great many times. Perhaps reading another article or paragraph would lead me to enlightenment, but alternatively, it could just be that X11 font management is a confusing glob of software that hangs together by faith and a bit of wizardry by the 3 people on this planet who really grok it all. Who knows? Anyway, I have no idea what PCF fonts are exactly, but I gather they're basically just bitmap fonts, and Ubuntu, by default, seems to not list these bitmap fonts in the font dialog.

After a bit of digging around, it seems that running dpkg-reconfigure fontconfig does some magic stuff and enables bitmap fonts. I say 'it seems' because I did a few other obscure things along the way, and one or all of them might have played a wee part in the solution, too. Next time I lose my fonts, though, that's the one I'm trying first. I might even bring myself to read the man page.

Other commands which I'll read up on when I'm bored one day:

fc-cache -f -v
dpkg-reconfigure fontconfig-config

The Ubuntu FontInstallHowto wiki page is somewhat enlightening.

Java might be WORA, but it doesn't necessarily follow from RA that one's code will work everywhere. One of my pet Eclipse RCP projects is a simple budgeting tool, and right now all it does is takes all of our downloaded bank statements and dollies them up a bit so we can browse our statements without having to go online.

I soon noticed two oddities when running the app in Gnome as opposed to Windows.

First, all the £ symbols in statement description fields were broken. Doh, I was using a FileReader to open the file. FileReaders just inherit the platform's default character encoding, which meant that on Linux, the default charset is UTF-8. The downloaded .csv files aren't UTF-8, they're ISO-8859-1 or whatever CP equivalent Windows uses. How often do Java developers take the time to think about and specify a character set when opening a file? Not often in my case, until tonight. How often do you even know what character set you're going to have to deal with? To work around the problem I had to subject myself to Java I/O constructor hell:

BufferedReader reader = new BufferedReader( new InputStreamReader( new FileInputStream(fileName), "ISO-8859-1"));

Second, I use JFace's FormToolkit to create web-style forms. I noticed that on Gnome, all form fields were missing their borders. Why? Turns out that internally, FormToolkit decides how to specify the border based on the current operating system, and for some reason, borders aren't set by default for Gnome. I'm sure there was a reason for this some time in the past, but this seems a bit broken to me, now. To fix it, I had to explicitly set a border style for the toolkit, and I'll have to remember to do it for every form I create down the line.

And hope that whatever new work I do, doesn't look too shitty on Windows.

Aug 1, 2007 12:08:15 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 666 ms

Server of the beast!

I realised last week that if I didn't get cracking, the day's going to come when I'll have spent an entire year with Windows XP as my home OS. Can't have that, what would all the cool kids say, so I decided enough is enough and I'm making a concerted effort to boot into Linux and stay there. The problem was that after shutting down my beloved Gentoo box last year and moving over here, it took so damned long to get everything set up in Windows on the new laptop, that I'm loath to have to start all over again in Linux. I can copy and paste a lot of config stuff from Windows and old Gentoo backups, but there's still a lot of schlep involved. But it had to be done. Frustrations aside, it's nice to be back.

Anyway, the change-over is also chance to do some housekeeping. Tomcat 6 got released a few months ago, so it's upgrade time. It implements the Servlet 2.5 and JSP 2.1 specs. Guess I should read the what's new articles (servlet, jsp).

... and I still haven't had a good look at what's new in Java 6.