FULL PRODUCT VERSION :
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
not relevant

EXTRA RELEVANT SYSTEM CONFIGURATION :
not relevant

A DESCRIPTION OF THE PROBLEM :
set/Anchor/LeadSelectionIndex(-1) results in firing a ListSelectionEvent with firstIndex = -1.

The issues are

a) the listSelectionEvent.getFirstIndex clearly states that the first/last index denotes a range of rows (that is a closed interval), the first row being 0. -1 is always outside.

b) it's inconsistent with "normal" selection events: they never include the -1.

c) the notification is asymetrical in set/clearAnchor: the set doesn't include the -1, while the clear (== setAnchor(-1)) does.

Whether or not to include the -1 was debated way back (f.i. #4140619 ) , the decision was not to which I think is a good one. Lead/anchor are just selection indices with a special tag, so I see no reason to produce different events on unselection

- there's no need to: the event contains the old anchor. Listeners have to check for the state of that index anyway (query selected, lead/anchor tags).
- it's not trying it's best to narrow the range of changes in the notification because it always grows the range from -1 to the actual changed index. Client code has to loop through all indices until the lead/anchor to check the state when in fact only the anchor/lead state of exactly one index changed.




STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
run the unit test

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
test passes: firstIndex == lastIndex == 1 on every notification
ACTUAL -
test fails: firstIndex == -1, lastIndex == 1 on setAnchor(-1)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
/*
 * Created on 23.10.2006
 *
 */
package bugs;

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

import junit.framework.TestCase;

/**
 * <code>DefaultListSelectionModel</code> creates illegal event on
 * <code>setAnchorSelectionIndex(-1)</code>.
 * This happens if the anchor
 * had been >= 0 before: event.getFirstIndex() is -1 <p>
 *
 * That's illegal because:
 * <ol>
 * <li> the api doc clearly states that the first/last index denote a range
 * of rows, the first row having the value of 0
 * <li> it's inconsistent with the behaviour of unselecting "normal" selection
 * indices, which never include the "unselected" -1 index.
 * </ol>
 *
 * @author 2006 Jeanette Winzenburg
 */
public class IlegalListSelectionEvent extends TestCase {
    public void testNegativeFirstIndex() {
        DefaultListSelectionModel model = new DefaultListSelectionModel();
        final int index = 1;
        ListSelectionListener l = new ListSelectionListener() {

            public void valueChanged(ListSelectionEvent e) {
                assertEquals("lastIndex same as index", index, e.getLastIndex());
                assertEquals("firstIndex same as index", index, e.getFirstIndex());
            }
            
        };
        model.addListSelectionListener(l);
        model.setSelectionInterval(index, index);
        // sanity: assert that the anchor is indeed set
        assertEquals("anchor same as index", index, model.getAnchorSelectionIndex());
        // clear selection to exercize the "unselect" notification for normal selection
        model.clearSelection();
        // clear anchor selection
        model.setAnchorSelectionIndex(-1);
    }
}


---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
workaround:
none from the outside (except expecting the misbehaviour and guard against the negative value). Inside - change markAsDirty to do does nothing on negative values.

There's a related bug: #6471404 which focuses on the consequences (negative index in table.valueChanged). Here we are at the root cause - plus the other has an evaluation I disagree with ;-)

Cheers
Jeanette