[Bug classpath/22982] swing: javax.swing.table.DefaultTableModel(null, anything) not handed

[gcc-bugzilla at gcc dot gnu dot org]

Steps to reproduce:
1. Run the attached testcase

Expected results
1. Program exists successfully

Actual results:
1. Program throws the following exception:
java.lang.NullPointerException
   at javax.swing.table.DefaultTableModel.setDataVector
(DefaultTableModel.java:186)
   at javax.swing.table.DefaultTableModel.<init> (DefaultTableModel.java:146)
   at javax.swing.table.DefaultTableModel.<init> (DefaultTableModel.java:157)
   at testcase.<init> (testcase.java:9)
   at testcase.main (testcase.java:5)


------- Comment #1 from from-classpath at savannah dot gnu dot org  2005-06-16 
13:18 -------
I think you forgot to attach the test case.

>From the line number in the exception, I figured that you are calling
DefaultTableModel(Object[][], Object[]).  The API spec (I'm reading 1.4.2) says
that this "initializes the table by passing data and columnNames  to the
setDataVector method".  And the setDataVector() spec says that a null 'data'
argument "results in unspecified behavior, an possibly an exception".

So the behaviour, although it is different to Sun's implementation, is
compliant with the specification, as far as I can tell.  It is probably
something that should be noted in the GNU Classpath API docs, which I'll fix
unless someone has different view.


------- Comment #2 from from-classpath at savannah dot gnu dot org  2005-06-16 
21:26 -------
Indeed, here's a testcase:

import javax.swing.*;
import javax.swing.table.DefaultTableModel;
public class testcase extends JFrame {
        public static void main(String[] args) {
                new testcase();
        }
        public testcase() {
                Object[] columnNames = { "column1" };
                new DefaultTableModel(null, columnNames);
        }
}
[


------- Comment #3 from from-classpath at savannah dot gnu dot org  2005-06-17 
11:02 -------
Ok, maybe there should be some throw UnspecifiedBehavior()? ;-)

Current behavior prevents hirudo from running with gnu classpath. I've reported
a bug against hirudo at

https://sourceforge.net/tracker/index.php?func=detail&aid=1222532&group_id=93171&atid=603407


------- Comment #4 from from-classpath at savannah dot gnu dot org  2005-06-18 
22:02 -------
I looked at the API some more and this is what I came up with, working
backwards:

(1)  The setColumnIdentifiers() methods specify exactly how the data vector
should be modified to match the new column identifiers (including the null
case).  No problem here.

(2)  The setDataVector() methods describes how a conflict between the
dataVector and the columnIdentifiers is resolved - it sounds a lot like the
data vector is set first, and followed by a call to setColumnIdentifiers().  It
mentions "unspecified" behaviour for a null dataVector - probably because JDK
1.3 and JDK 1.4 behave differently (see bug report 4348070) and the spec has
been written to fit that.  JDK 1.4 doesn't throw an exception, so it seems
likely to me that the null vector is replaced by a zero length vector.

(3)  The spec for the constructors mentions passing off to the setDataVector()
methods, so the behaviour will follow the description in (2).

I'm going to try changing the setDataVector() method to replace null with a
zero length vector, add a few extra Mauve tests, and see if this gets around
your issue.  (I'm short on time this week, but I'll get back to it next week if
necessary).


------- Comment #5 from from-classpath at savannah dot gnu dot org  2005-06-24 
12:01 -------
I submitted a patch to the classpath-patches mailing list and will wait for
approval to commit it to CVS.


------- Comment #6 from from-classpath at savannah dot gnu dot org  2005-06-24 
12:42 -------
I haven't received the email yet, but I also have checked in some fixes for
JTable related stuff. I don't think that this overlaps, but you better check
it.


------- Comment #7 from from-classpath at savannah dot gnu dot org  2005-06-24 
21:17 -------
There was an overlap between my patch and yours - I added some more Mauve
checks, amended my patch and committed it to CVS.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22982