Command line: A universal programming blindspot

Every major OS today enables you to create a file whose name begins with a hyphen. Hence filenames like --help are legitimate on most systems. So is --help.class. If your class has this perfectly legal name, Java will not ever execute it. The reason is that its command-line parser (like most) is wedded to the belief that a switch character (the hyphen) will be used strictly for switches, so the parser never tests for a file name that begins with one.

I can find no parser, program or code snippet in all the code I have access to (open and closed) that checks for this possibility. Moreover, I can find no discussion of this issue. It's a true blindspot.

Of course, the problem is much greater than just Java. Most Linux and UNIX software uses the hyphen as the switch character for command-line args. Curiously, this problem does not exist in Windows, because the universal command-line character is a forward slash (/), which is not allowed in file names.

This problem points out the fact that despite the long push towards code inspection, code analysis, unit testing, etc. that has occurred during the last decade, these tools are only as good as the perceptions of the developers writing and using them. Hence, widely pervasive beliefs are still going to infect even our best efforts, until we begin to really think outside the box of our own prejudices to get at subtle aspects of software quality. I will have more on these blindspots in later posts.

SWT: Both better and lesser than Swing

I've spent time these last few days coming up to speed on SWT. You know, the usual exercises of making progressively more complicated interfaces that rely on more numerous widgets with advanced features. I am struck by two things in SWT. The first is a benefit that is rarely touted: it's much simpler to code in SWT than in Swing. It takes fewer lines of code and, more importantly, you don't have to descend so deeply into the bits and bytes to be productive. Generally people point to SWT's use of native controls as its big advantage, but the easier coding is a definite benefit. For straightforward interfaces (no more complicated than Eclipse, for example), it's clearly the way to go. However, I was disappointed to find that it has no capabilities to handle rich text. It certainly handles text, but not rich text (with multiple different fonts in different sizes using different colors). JFace, the toolkit that rides above SWT, has some additional text support, but nothing close to real rich text. For this, you are obliged to use Swing. So, ultimately, I conclude that I will use SWT whenever I can, and rely on Swing for all the other applications. It's a shame really, because it would seem to me that adding the equivalent of editor toolkits to SWT would make it a feature-complete widget set.

Good book for learning JSPs and servlets

As I have been studying up on servlets and JSPs, I have found one book to be particularly useful: "Head First Servlets & JSP" from O'Reilly and Associates. The whole Head First series has a sort of whimsical dimension to it. The design is slightly to entertain as well as instruct. I found this approach a little tedious in the original volume in the series "Head First Java." This book is better done and the content is provided by the two engineers who wrote Sun's certification exam on servets and JSPs. It's probably the best book around for taking you from a dead halt (knowing little or nothing about the topic) to fully proficient. Like the other Head First books, it's purely a tutorial and not meant as a reference. So, if you already know a fair bit about the topic and just need help in specific aspects of a topic, the book is probalby not for you. Otherwise, it might well be the fast, most enjoyable, and most memorable way to become great with servlets.

Technocrati Registration

Technorati Profile