Comparing Strings For Equality

Thursday, February 24th, 2005

Java’s slogan is “Write once, run anywhere”; but perhaps it should be, “Write once, run anywhere except Turkey.” Java is a wonderful programming language that’s loved and adored around the world, but not in Turkey, a nation of more than 60 million people. Nor is Java all that popular with the millions of Turkish speakers outside of Turkey. Sun didn’t use the Turkish flag to diaper the tiger cub at JavaOne 2004, but for all the adoption Java’s seen in Turkey, they might as well have. It’s not just the Java language that’s unpopular, either. Most programs written in Java that run just fine in the United States exhibit intolerable bugs in Turkey.

(more…)

Overloading int considered harmful: part 2

Sunday, December 19th, 2004

After writing Overloading int considered harmful, three concerns were raised:

  • How does this affect object serialization?
  • What about ClassLoaders?
  • How about the new enum keyword in Java 1.5?

I’d like to address those now.

(more…)

HTML Labeled Components

Tuesday, December 14th, 2004

One of the coolest yet little known features of the Java Foundation Classes (aka Swing) is the ability to label components with HTML. For example, let’s suppose you want a button that contains both bold and non-bold text on separate lines like this:

Button text: Damn the Torpedoes! Full speed ahead!

This is quite complex to implement in Java code. You have to subclass JButton, override paint(), and perform many detailed calculations with FontMetrics objects just to decide where to draw the different text strings. On the other hand, it’s straight-forward code this in HTML:

(more…)

Overloading int considered harmful

Thursday, December 2nd, 2004

When I was writing JavaBeans: Developing Component Software in Java, I lost over a day hunting for one bug. The program compiled and ran; but a label that was supposed to appear in the GUI wouldn’t show up, no matter what I did! The problem turned out to be in this line of code:

Font f = new Font("Serif", 12, Font.BOLD);

Can you see the bug? It’s certainly not obvious. In fact it’s so inobvious that I’ve made this mistake probably a dozen times since then, and it’s been a hard one to find every single time. I almost guarantee you can’t spot the bug without looking at the declaration for the Font constructor:

(more…)

ProgressMonitorInputStream

Thursday, December 2nd, 2004

In Java I/O, I wrote a Swing based GUI program that could display any file in a variety of encodings such as hex dump or ASCII. A screen shot is shown below. You can find the actual program source at Cafe au Lait or in Chapter 13 of Java I/O.

The biggest problem with this program is that after clicking the “View File” button, the user may have to wait for several seconds to several minutes before the file is displayed. Reading in a multi-megabyte file and converting it to a hex string is slow, even on a relatively fast machine with a fast hard drive. While the file is being read from the disk, the program is effectively frozen from the user’s perspective. This is not a good thing. Although there are undoubtedly still some optimizations that could be performed on the code to make it run faster, no matter how much it was optimized you could always throw a larger file at it that would make it seem frozen once again. Consequently I want to focus here not on optimizing the code, but on changing the user interface to make the program at least appear more responsive.

One general principle of user centered program design is to always give the user feedback, even if the feedback is no more significant than “Yes, I’m still running; No I haven’t frozen.” For simple operations an animated cursor like the Macintosh’s spinning beach ball may be sufficient . For longer operations, you should display a progress bar that indicates how much of the operation has been accomplished and how much remains to be done. Swing 1.1.1 lets you easily display progress bars in JOptionPanes like the one shown below:

(more…)