Recently in Java Category

While getting my daily fix of feed, I found this post on javablogs, describing a "bug" that crawled into the code because a design decision.

The problem they actually had was conceptual one, more than technical. The Comparable interface is meant to be implemented if there is an ordering that inherent to the class (ie, numbers, words, days of week, months, seasons). In their case, ordering by name is not inherent to the SelectablePerson class (you may want to sort by any other field in the future).


I'll follow with another Java quirk in my next post.


I was working in the same application where I found the previous quirk. This time I tried to make a cell renderer put a background color in the cell, to no avail. I even tried to explicitly return a JLabel as the cell renderer, with the proper background color set. Nothing.

The answer to the mystery is the fact that JLabel is transparent by default, transparent components don't render their background, and DefaultTreeCellRenderer extends JLabel.


I have been bitten. ListSelectionListener.valueChanged is called more than once when a selection in a List/Tree/Table is changed. After some googling, I found out that I'm not alone.


I was doing some regexp work on one of my projects, when suddenly this well-known and hundred-of-times implemented code right from the javadoc, failed:

   StringBuffer result = new StringBuffer(text.length());
   while (includeMatcher.find()) {
      String includeFile = includeMatcher.group(1);
      String s = readTemplate(includeFile, area,topic,skins,false);
      includeMatcher.appendReplacement(result, s);
   }
   includeMatcher.appendTail(result);
   text = result.toString();


A java.lang.IllegalArgumentException was thrown.

Thanks to google, I found out what happened: There was a $ sign in the replacement string.
Now, of course this was mentioned in the Matcher javadoc but nowhere in the documentation is stated that an IllegalArgumentException will be thrown.

Just for the record: the solution I implemented was to insert the following line just before the appendReplacement call:


s=s.replaceAll("\\$","\\\\\\$")


Hope this post helps someone in the future.

Update: One commenter gave another solution:

Since Java 1.5 you can do

s = Matcher.quoteReplacement(s)



(reposted from a long-forgotten blog)

There used to be a movement to promote the creation of complex GUI using XML. This seems like a good idea, if you can find a nice way to express what you want.

IMO, the flaw in the implementations I have found so far is that all of them seems to mix up both definition of the component (properties, etc), the behavior of the component (Listener registration) and the Layout. Everything is thrown in the same bag and shaked. It's just a way to express things with XML instead of Java, so there is no true advantage to that approach unless you want to cut down the compilation process (see [1]).

So, why would I want to represent a GUI as XML?... I can see two reasons:
 * Ease the GUI manipulation by tools
 * Tackle the complexity of GUI building with Awt/Swing

The first one is pretty much straightforward: It's easier to maintain a script that has a well known (albeit rigid) semantic than to maintain a class that the programmer will try to modify to bend it to it's will.
The second point raises an interesting question: Is really that complex to create a GUI? If so, why?

Most Java  programmers I know tremble at the mention of two dreaded words: SWING and AWT. Those few braves who don't tremble, but are willing and sometimes eager to dive in the complexity of building, GUI start to shake at the mention of one "simple" class: GridBagLayout. This layout is famed for it's flexibility and complexity... Add this to the fact that struggling with the layout managers, preferred sizes, layout hints and so on to make the components be displayed the way we want can be one of the most titanical and time-consuming task in the GUI development and you can see that making a good GUI in Swing can be daunting to some people.

But what if laying out the GUI were a task as simple as building an HTML table? Perhaps this first barrier would be lifted and the programmer can concentrate in what he knows best: To program logic.