Recently in Java Quirks 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.