Finding bugs part 2
If by some freak accident of nature you’ve managed to last this long, it’s ready to finally ‘find bugs’. Here we have more unwelcome anal intrusions in the form of a modal progress dialog. The progress dialog will happily write things to the UI console, except that because it’s modal, you have no way of actually looking at all the things it’s whining about. Of course, the warnings are deliciously verbose too, with every line beginning with a full timestamp and the fully qualified class name of the internal handler that reported the issue. I am utterly baffled by this classname fetish that opensores projects have. What exactly do you people get from showing your classnames to your end users? Is it some kind of freakish penis waggling maneuver? A bizarre mating ritual? Emotional issues resulting from being beaten and molested as a child?
Of course, the modal progress dialog has a cancel button, and if you press it you get….another modal dialog, asking you to confirm. Now I’m no grizzled UI veteran, but in all my years of using computers, I have yet to find an OS with such a bizarre paradigm. Real innovation here guys, a modal dialog with one button, that confirms with another modal dialog when you press said button.
The default settings are also of highly dubious quality. Every time you return a Date field for example will cause findbugs to throw a hissy fit. Ignoring results from reading streams (something which is often perfectly legitimate) is also whineworthy.
Of course, should you wish to change these detectors, your eyes will be stabbed yet again with this unfathomable UI. You’re presented with a JTable where the detector fully qualified class names are listed, along with ’speed’ and ‘enabled’ columns. Of course, since it’s open source, nobody knows how to actually use a JTable, so the columns are all the exact same size. This results in every single class name being truncated, for your maximum viewing pleasure.
