Bad tools

Not to seem like I'm down on Sun or anything, but I can only assume that they really want us to avoid using their command line tools for Java development. First it's the Java runtime complaining about a class not found when really the class is there, it's a class that it depends on that's missing. Then, while using "jarsigner" today I get this error:

[signjar] java.lang.InternalError: jzentry == 0,

[signjar] jzfile = 10414112,

[signjar] total = 1555,

[signjar] name = C:\development\invision.ui.web\clovis_view.jar,

[signjar] i = 1,

[signjar] message = couldn't read LOC header

[signjar] at java.util.zip.ZipFile$2.nextElement(ZipFile.java:321)

[signjar] at sun.security.tools.JarSigner.getManifestFile(JarSigner.java:985)

 ...

"Oh no, that looks serious, I have a corrupt JAR file" was my natural response. Rebuild JAR file. Same error. Turns out that, although jarsigner allows you to specifiy the same source and target file, it doesn't quite go as far as actually handling that and tries to read and write to the same JAR file - bad. A simple if (inputFile.equals (outputFile) <warn poor sod user I can't do that> would have saved me, and probably 5,000 other programmers 10 minutes of time.

Swing "Hi-Fi"

This article from a Sun engineer working on Swing in JDK 1.6 ("Mustang") and the comments it inspired revisit some of the Swing issues I've banged on about before. Here's an excerpt:

In Tiger and Mantis, we have provided support for the Windows XP look and feel. The mechanism used to provide this support was based on reading the resources embedded in the XP styles files and using those icons and colors to render our Windows Look and Feel. Unfortunately, Microsoft has changed the Styles files in Longhorn so that the resources are no longer visible using the mechanism we used in Tiger and Mantis
[...]
We talked this over with engineers from Microsoft's graphics team, they suggested that the way to work with the Longhorn themes was to use the UxTheme API. So Leif Samuelsson (Swing Windows Look and Feel Author) and I prototyped a version of the Windows XP Look and Feel that uses the UxTheme engine to perform the rendering of Swing components.

And one of the responses:

I for one am not holding my breath. This very approach was suggested to Sun three years ago in bug #4587653, right down to the names of the API functions to use. It has even been submitted multiple times by independant posters. But it has consequently and repeatedly been turned down by reviewers in favor of the always-trailing-behind bitmap copycat approach.

Obviously he's been in the same situation I have: he's tracked problems, suggested solutions, voted for them, and then waited years for any acknowledgement that there's even a problem. And then the Sun guy actually seems to be expecting people to congratulate them on finally doing it the right way instead of the unsupported hack they're using right now. And we'll have to wait another JDK cycle (18 months) before we can use this.

This guy goes on to say:

Surely, no future builds of Mustang will look any more native than the current one before the font support is fixed, too. Don't bother suggesting any APIs for this, however. That should be considered redundant as the issue will probably be talked over with some Microsoft engineers already around the end of this decade.

Sounds bitter. I feel his pain ;)

Another interesting comment:

Natively themed drawing means that you're using the toolkit's functions to perform the painting, but without having any of its structures associated with the component. This still doesn't save you from the anomalies stemming from a mock user interface, but at least it looks the same. [...]

It is often portrayed as the only way to achieve platform-independant user interfaces (why anyone would want that is above me), but in reality it is more like writing your own filesystem on top of the disk driver.The real reason it is done is probably because the model of custom drawing fits better with the garbage collector in Java. You still have to close your files explicitly, but nobody is complaining about that, though.

The comparison with emulated Swing and wrapped native IO is telling. Anti SWT pundits often claim that disposing widgets is "non-OO" (whatever that means), but rarely realise there are quite a few real-world operations that unfortunately don't fit the GC model. If Sun had written it's own filesystem implementation to avoid having to do icky things like close () files, people would have agreed that was insane. When they decided to write an entire widget framework and graphics stack, the major part of a modern OS's interface with its user, somehow that didn't sound insane.

This article is particularly apt, coming as it does as the latest Swing Sightings article goes out. There are some truly excellent and sophisticated apps in that selection. And all the good examples in there contain workarounds for Swing's L&F issues. Either they use one of the extended L&F's, or they apply WinLAF-style tweakage. If the Sun guys hadn't painted Swing into such a corner, these sorts of uber-apps might have appeared 4 years ago and blown people away compared to the dull Windows apps of the time.