Recently in Java Category

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.

After some googling again I found out that I'm not alone. There is even a bug raised, and closed as "not a bug". From the JComponent.setOpaque() javadocs:

    /**
     * If true the component paints every pixel within its bounds. 
     * Otherwise, the component may not paint some or all of its
     * pixels, allowing the underlying pixels to show through.
     * 

     * The default value of this property is false for JComponent.
     * However, the default value for this property on most standard
     * JComponent subclasses (such as JButton and
     * JTree) is look-and-feel dependent.
     *
     * @param isOpaque  true if this component should be opaque
     * @see #isOpaque
     * @beaninfo
     *        bound: true
     *       expert: true
     *  description: The component's opacity
     */

The workaround? Add this.setOpaque(true) in the overriden getTreeCellRendererComponent() method:

public class BagroundColorEnabledRenderer extends DefaultTreeCellRenderer {
    public Component getTreeCellRendererComponent(JTree tree, Object value, boolean sel, boolean expanded, boolean leaf, int row, boolean hasFocus) {
	super.getTreeCellRendererComponent(tree,value,sel,expanded,leaf,row);
	this.setOpaque(true);
	return this;
    }
}

Happy Coding!

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.

The fix is quick enough, but I was curious about why was happening, so I hacked up the following test program:

package org.soronthar.spikes;

import javax.swing.*;
import javax.swing.event.ListSelectionListener;
import javax.swing.event.ListSelectionEvent;

public class ListSelectionSpike extends JFrame {

    public static void main(String[] args) {
        ListSelectionSpike spike = new ListSelectionSpike();
        spike.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        JList jList = new JList(new String[]{"One", "Two", "Three"});
        jList.getSelectionModel().addListSelectionListener(new ListSelectionListener() {
            public void valueChanged(ListSelectionEvent e) {
                if (e.getValueIsAdjusting()) {
                    System.out.print("Adjusting ");
                }
                System.out.println("f:" + e.getFirstIndex() + " l:" + e.getLastIndex());
            }
        });
        spike.getContentPane().add(jList);
        spike.pack();
        spike.setVisible(true);
    }
}

After some toying, I found out that valueChanged is called once each time the mouse is pressed and the selection changes without releasing the mouse, and once more when the mouse is released. That means that if you press the mouse, move over all the elements of a list and then release the mouse, valueChanged will be called once for each element plus once at the end (n+1 calls).

If you change the selection using the keyboard, then it gets called once.

I checked the javadocs for ListSelectionListener and the Swing tutorial, and it seems that this behavior is not documented.

After some more digging, I found out that it was even reported as a bug long time ago, and it was closed as "not a bug".
The workaround? Implement your valueChanged method as follows:

           public void valueChanged(ListSelectionEvent e) {
                if (!e.getValueIsAdjusting()) {
                    //do my stuff
                }
            }

The key is that while the mouse is pressed, all the ListSelectionEvents will return true for the e.getValueIsAdjusting() call, and will only return false when the mouse is released. For keyboard operations, it always returns false.

Hope this helps someone. Happy coding!

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.

(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.