Seems like there is more then one bug when playing with that table example.
I used the following SSCCE which works as expected under JDK1.6
import javax.swing.*;
import javax.swing.event.*;
import javax.swing.table.*;
public class TableBugDemo {
public static void main( String[] args ) {
JFrame frame = new JFrame( "TestFrame" );
final JTable table = new JTable( new SpyModel() );
table.getSelectionModel().addListSelectionListener( new ListSelectionListener() {
@Override
public void valueChanged( ListSelectionEvent e ) {
Thread.dumpStack();
System.out.println(table.getSelectedRow());
}
} );
frame.add( table );
frame.setDefaultCloseOperation( WindowConstants.EXIT_ON_CLOSE );
frame.pack();
frame.setVisible( true );
}
public static class SpyModel extends DefaultTableModel{
public SpyModel() {
super( new String[][]{
new String[]{ "row1-1", "row1-2", "row1-3"},
new String[]{ "row2-1", "row2-2", "row2-3"},
new String[]{ "row3-1", "row3-2", "row3-3"},
new String[]{ "row4-1", "row4-2", "row4-3"},
}, new String[]{"col1", "col2", "col3"});
}
@Override
public void setValueAt( Object aValue, int row, int column ) {
System.out.println( "TableBugDemo$SpyModel.setValueAt" );
Thread.dumpStack();
super.setValueAt( aValue, row, column );
}
@Override
public boolean isCellEditable( int row, int column ) {
return false;
}
}
}
Under JDK1.7 however:
I see the setValueAt being called when making the table editable. However, not with an empty string but with the actual values which are contained in my TableModel. This means that nothing is changed to my data. Only annoying thing is that during the navigation my table is constantly updating. Workaround is of course to adjust the setValueAt method with a quick exit path when the value is not updated at all, e.g adding
if ( ( aValue != null && aValue.equals( getValueAt( row, column ) ) ) ||
( aValue == null && getValueAt( row, column ) == null ) ){
return;
}
Navigating with the up and down arrows make the selection jump 2 rows at a time. Stacktraces reveal the change in selection originates from the BasicTableUI#Actions class (which makes sense as that is the action which is placed in the action map). The weird thing is that for one key-press this action is triggered twice. That already explains why the selection jumps 2 rows at a time. Further debugging revealed that for hitting my arrow key once I received two distinct KEY_PRESSED events. As far as I can tell, those event are placed like that on the EventQueue and have nothing to do with the JTable. Just to make sure, I created a small SSCCE which does not include a JTable:
import javax.swing.JFrame;
import javax.swing.WindowConstants;
import java.awt.AWTEvent;
import java.awt.EventQueue;
import java.awt.Toolkit;
import java.awt.event.AWTEventListener;
import java.awt.event.KeyEvent;
public class KeyEventBugDemo {
public static void main( String[] args ) {
EventQueue.invokeLater(new Runnable() {
@Override
public void run() {
JFrame testframe = new JFrame( "testframe" );
testframe.setSize( 300,300 );
testframe.setDefaultCloseOperation( WindowConstants.EXIT_ON_CLOSE );
testframe.setVisible( true );
}
} );
Toolkit.getDefaultToolkit().addAWTEventListener( new AWTEventListener() {
@Override
public void eventDispatched( AWTEvent event ) {
if (event instanceof KeyEvent ){
KeyEvent keyevent = ( KeyEvent ) event;
System.out.println( "keyevent.getKeyCode() = " + keyevent.getKeyCode() );
System.out.println( "ID = " + System.identityHashCode( keyevent ) );
System.out.println( "keyevent = " + keyevent );
}
}
}, AWTEvent.KEY_EVENT_MASK );
}
}
Giving focus to the frame and then hitting the DOWN_ARROW results in the following output (stripped the output of toString to keep it readable)
keyevent.getKeyCode() = 40
ID = 960135925
keyevent = java.awt.event.KeyEvent[KEY_PRESSED,keyCode=40,...
keyevent.getKeyCode() = 40
ID = 1192754471
keyevent = java.awt.event.KeyEvent[KEY_PRESSED,keyCode=40,...
keyevent.getKeyCode() = 40
ID = 2012032999
keyevent = java.awt.event.KeyEvent[KEY_RELEASED,keyCode=40,...
Here you can clearly see that you get two KEY_PRESSED events which confuse the JTable. This does not occur when using a regular character key
keyevent.getKeyCode() = 65
ID = 1023134153
keyevent = java.awt.event.KeyEvent[KEY_PRESSED,keyCode=65,keyText=A,
ID = 914147942
keyevent = java.awt.event.KeyEvent[KEY_TYPED,keyCode=0,keyText=Unknown
keyevent.getKeyCode() = 65
ID = 986450556
keyevent = java.awt.event.KeyEvent[KEY_RELEASED,keyCode=65,keyText=A,keyChar='a',
Looking at the javadoc in the KeyEvent class:
KEY_TYPED (is only generated if a valid Unicode character could be generated.)
it makes sense I won't get the KEY_TYPED event when hitting the arrow, but that it fires the KEY_PRESSED twice is in my opinion a bug (will log a bug report later on for this). A workaround might be to intercept such an event and not pass it through the chain but that sounds like an ugly hack to me.
EDIT
Another weird thing. If you add the following line to the snippet
table.getInputMap( JComponent.WHEN_ANCESTOR_OF_FOCUSED_COMPONENT ).
put( KeyStroke.getKeyStroke( 'a' ), "selectNextRow" );
you can use the a to jump to the next line (same action as which is triggered by default by using the DOWN_ARROW). Due to the correct sequence of events when pressing a, it seems the setValueAt method is also not called. This makes me think that the two KEY_PRESSED events starts the editing somehow ...
