Knute Johnson wrote:
Brandon McCombs wrote:
Knute Johnson wrote:
Brandon McCombs wrote:
Hello,
Somewhere in my code I have a bug that I can't reliably reproduce.
It occurs randomly when I'm deleting entries from a JList (I
retrieve certain pieces of info from the entry before deleting it,
then I delete it and the JList contents are then refreshed so
remaining items are re-added to the JList). The only output I get
when the exception occurs is the following:
Exception in thread "AWT-EventQueue-0"
java.lang.ArrayIndexOutOfBoundsException: 1 >= 0
at java.util.Vector.elementAt(Unknown Source)
at javax.swing.DefaultListModel.getElementAt(Unknown Source)
at javax.swing.plaf.basic.BasicListUI.paintCell(Unknown Source)
at javax.swing.plaf.basic.BasicListUI.paint(Unknown Source)
[snip]
The "1" as the index value differs between exception printouts. I
don't know where that index value is originating from or what
Vector is really having its elements retrieved. The index value
doesn't correspond to the index of the Object that I'm selecting
for deletion. I've placed try/catches throughout the places where I
thought was causing the exception to print out a stacktrace that I
hoped would include a line number but I'm not getting any extra
output. I also would put in a print statement so I knew which
try/catch was being executed but I don't see that outputted either.
When the JList is refreshed it is done so through a thread. I've
tried to use run() to make the thread do its work but not in a
thread and I don't get the exception but since I can't reproduce it
reliably I don't know if it's really a threading problem or not.
Using Eclipse's debugger also doesn't help so far because I can't
get the error to occur during the debugging, at least not yet.
Is there anything else I can try that can give me more information
as to what line in my code this is occurring on so I can begin to
fix it?
thanks
Are you modifying the JList on the EDT? Are you modifying the
Vector after creating your JList? Can you make a simple test
program that demonstrates the problem?
The code that the Thread class uses to tell the JList when to update
is this:
SwingUtilities.invokeLater(new Runnable() {
public void run() {
component.updateGUI(results);
component.resetGUI(results);
}
});
Component is the class that contains my GUI which is a JTree and
JList in a JSplitPane; component is passed into the Thread's
constructor.
Results is a Vector that contains the results of a LDAP search which
will be put into the JList.
Yes I'm modifying the Vector. Since the JList can have entries
added/modified/removed the Vector will obviously be changed
accordingly (as I state in the original mesg). I can't make a simple
test program because I don't know where the problem is. If I did I
wouldn't have posted this because I'd be working on figuring out a
way to fix it. The problem could be in a lot of places and ripping
out stuff to duplicate the problem would be a waste of time I believe
since I can't reproduce it not to mention the code involved is spread
across multiple classes. To test it I'm having to create temporary
entries in my LDAP server and then delete them one by one to see if
the error occurs. Sometimes I delete 50 before it crops up, other
times I delete 1 and the index value mentioned in the exception never
corresponds with the deleted entry.
I'm mainly asking if there is a way to glean more info from the
exception information. I can't believe it isn't giving me a line
number to review. Is the printout I originally posted the only stack
trace information available from the JVM? I've put whole method
bodies in a try/catch and I don't get any more information so either
I won't get more information or I'm putting try/catches in the wrong
place. Can the JVM be launched with options that will help?
Brandon
Brandon:
I think you are attempting to access a non-existing element or you've
been modifying the Vector itself which is not good either. If you
want to add and remove elements from a JList you need to use a
ListModel that is read/write. So since you can't make a test program,
shows us snippets of the critical code where you create the JList and
modify it.
Well the deletion still works when I get the exception. I am doing the
deletion by going through the ListModel for the JList which I thought
was correct. I never knew you could create a read-only ListModel.
I use the following as the constructor to my BrowserModel class which
contains 2 models for my Browser (JTree and JList I mentioned before):
public BrowserModel(Node root) {
this.root = (Node)root.getChildAt(0);
tree = new DefaultTreeModel(root);
list = new DefaultListModel();
}
The method I call for deleting a selected item from the JList is the
following (model is the instance of BrowserModel):
private void list_deleteObj() {
int idx = dirList.getSelectedIndex();
String dn = LDAPMgr.ldapUtility.getDN(
model.getListModel().getElementAt(idx) );
int ans = JOptionPane.showConfirmDialog(this,
"Confirm delete for:\n" + dn + "\n",
"Delete Object",
JOptionPane.YES_NO_OPTION,
JOptionPane.PLAIN_MESSAGE);
if (ans == 1)
return;
String msg = null;
msg = LDAPMgr.ldapUtility.deleteEntry(
model.getListModel().getElementAt(idx));
/* if successful */
if (msg == null) {
model.getListModel().remove(idx);
/* reload the subtree and list to show deletion */
refresh();
}
}
The idx in the code above rarely matches (if ever) the index value
listed in the generated exception and again, the deletion above still
works when the exception is generated. Refresh() essentially determines
which node in the JTree needs refreshing and then calls expand(node,
node.getDN()). Expand() removes all the node's current children and
spawns the thread to retrieve the current children. The items in the
JList are the children of the selected Node in the JTree.
The thread is spawned with this:
selectedNode = node;
searchBase = dn;
if (asyncSearch != null)
asyncSearch.stopSearch(); //allow 1 search at a time
asyncSearch = new AsyncSearch(this);
asyncSearch.setSearchBase(searchBase);
asyncSearch.setFilter("(objectClass=*)");
asyncSearch.setReturnedAttributes("*");
asyncSearch.setScope(1);
asyncSearch.start();
That calls a method that executes a LDAP search and passes the results
back to the Browser class by calling updateGUI() from the Browser.
Within updateGUI() the Browser populates the selected node's children in
the JTree as well as the JList (which is just another view of the node's
children). If I do this whole process enough times I get the
aforementioned exception.
I hope that description is helpful and understandable.
If you can figure this one out I'd appreciate it because I don't even
know where to look since nothing is making sense (index values not
matching up, deletion still works).
thanks for the help
I don't see anything there, nothing looks out of the ordinary. Any
I think this is going to be hard to find without a simpler test program.
I had a problem like that once though that I couldn't duplicate. I
thought the problem was occurring. That was kind of a shotgun approach.