Fixing WM_CLASS for your Java application's windows

X11 windows can have arbitrary properties set on them. There are various conventional properties, and they're read by tools like window managers and task bars and window switchers and the like.

For example, if you have too many open windows on a GNOME desktop, instead of getting one task bar icon per window, you get one per application. Where does the application name come from? From the WM_CLASS property on those windows.

As another example, if you use the screenshot tool in Sun's Java Desktop System release 3 to take a picture of a single window, the default filename contains the application name. Where does the application name come from? From the WM_CLASS property on the window.

So where does the WM_CLASS property come from in a Java application? The fully-qualified name of the class at the bottom of the stack trace when the Toolkit was constructed, with the dots replaced by dashes.

So what's a Java programmer to do to avoid his application appearing to the user to be called org-jessies-app-Main, or something daft like that?

One choice is that you ensure that your main class is in the default package and has the name of your application. But that's ugly, awkward, and a pain if your application's external name doesn't match its internal name.

Another, better, choice would be to override the value that the X11 Toolkit uses for WM_CLASS. Sadly, there's no API for this. No magic property or environment variable you can set. On the bright side, the current implementation caches the value it'll use for all windows when the Toolkit is constructed. So, unlike if it were a private method in default-access class in an undocumented package, you can easily use reflection to override the default:

Toolkit xToolkit = Toolkit.getDefaultToolkit();
java.lang.reflect.Field awtAppClassNameField =
awtAppClassNameField.set(xToolkit, applicationName);

Surround that with a try/catch and log errors such that if you ever find yourself wondering why your windows have the wrong WM_CLASS (if Sun change this implementation detail in Java 8, say), you'll have a clue lying around.

If your code only ever runs on Mac OS or Windows, you don't need to worry about this (though on Mac OS you'll want to worry about -Xdock:name). But if you're expecting users on Unixes other than Mac OS, this is a worthwhile bit of polish.

I've submitted an RFE. Sun bug 6528430.


Non-Review: Sony Reader

I almost bought a Sony product the other day. The (other) evil empire, fount of rootkits, source of DRM, and lover of lock-in, Sony, managed to turn my head. They didn't manage to sell me anything, but they came as close as they've come in years.

The product in question was the Sony Reader. It's one of those e-paper electronic book jobbies. I've been reading about e-paper displays for years, but, living under a rock, this was the first time I'd actually seen one. Wow. The reason my head was turned was because I was going to go over and laugh at this crappy cardboard mock-up of a product. As it turned out, it wasn't cardboard. The display really is that good. Seemingly it's about 160 DPI, which is better than the display you're reading this on (unless you're from the future), but not as good as the high-end desktop displays we'll have in a couple of years. It's "only" 4 bits per pixel, but compared to 1 bit per pixel displays, the extra grays also make a huge difference. This is the closest I've ever seen a display come to being as pleasant to read as paper.

What's not to like?

* It feels cheap and plasticy, and it's very thin. It's good, I suppose, that it's not heavy and large, but it feels breakable, it feels nasty, and doesn't feel like a USD350 product at all. It's not nearly as comfortable as a real book. To be honest, I would prefer that it was at least as heavy as a small paperback novel. I'd also like to fold it open like a book (or Nintendo DS) and have two "pages"; I think I'd feel the device was more protected when closed that way too.

* The UI is awful. Really terrible. It's partly crippled by the hardware. It turns out that these e-paper displays update really slowly. Insanely slowly. And, though I'm not sure whether this is the hardware or software's fault, and I don't understand why they couldn't have worked around this in some way, the screen flashes black whenever it updates. So not only is turning the page really slow, it's really ugly too.

* The UI is awful, part II. You might imagine that you could search an electronic book; that searching would be one of the main advantages of electronic books. Not this electronic book. No keyboard (physical or on-screen), no search, no annotations.

* The UI is awful, part III. There are handy next/previous page buttons, but if you're on a "menu" page, like the one to select a book, or select a chapter, there are numbers along the right-hand side of the screen. Where did Sony put the physical buttons that correspond to these on-screen numbers? Yep, along the bottom of the screen. I really have no idea what they were thinking. This is such a bad mismatch that I didn't even realize what those buttons did until I read the built-in manual! And don't think you can use those buttons numbered 0-9 to enter page numbers. You can't.

* The UI is awful, part IV. There's an alternative way to use the menu, thanks to a crappy little rubber nipple in the bottom-right corner, but that was quite awkward to use, and treats you to a slow and ugly animation as the currently-selected item indicator crawls up or down. Only a dead stoner would have the patience to use that.

* The UI is awful, part V. So you can't search, and turning pages is slow... At least there's some form of fast-forward for "flipping through" the pages, right? Nope.

* Good for text, not so good for images. Text looks great on this display. The high DPI and the 4 bits of gray make for very nice text, by any contemporary standards. Pictures? There weren't many on the demo device, but there certainly wasn't anything that didn't look a bit, well, crap. It's probably the high quality of the text that makes the images look so bad, but these days we're used to a lot of color depth in our portable devices. Anyone who's seen an iPod nano is going to think this is something out of the ark.

* The display is really small. Fine for a paperback novel, no good for any reference book on my shelf at the moment.

* Though it runs Linux internally, it's not compatible with Linux. The supplied software and DRM is Windows-only. The internet suggests that some people are reverse-engineering the protocol to provide support for other OSes, but I'm only going to support a product that requires me to use reverse-engineered tools/drivers if I don't have a practical choice (as with, say, discrete graphics cards). And if Sony's companion software is as bad as the software on the device... Ugh!

* There's no backlight. While this is good if you're somewhere well lit, because the reflective display is, like real paper, much easier on the eyes than an actively-lit display, it sucks in the dark. True, a real book doesn't have a built-in light either, but a built-in light feels like one of the advantages an electronic book ought to offer.

* There's still no convenient book equivalent to ripping a CD, so this can't yet offer a market like the iPod. I'm sure Sony see this as an advantage, but no sane consumer wants to re-buy all their books.

I tell you, though: that display is nice. In a few years, from a company less keen on lock in that Slimy Sony, something like this might be pretty cool. At the moment, this has none of the advantages an electronic book ought to have (other than weight that isn't proportional to the amount of text) and plenty of disadvantages that real books don't have.