«

Brandon McCombs wrote:

> 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?

People downthread are already speculating that the problem is caused by
modifying the model from outside the EDT; I suspect that they are correct.

I just wanted to add (for general info) that the version of rt.jar which comes
with the JRE is (at least in 1.5 and 1.6 on my machine) compiled without line
numbers -- whence the less informative stack trace. The equivalent rt.jar
which is part of the JRE which is inside the JDK /does/ have that information
(again, as far as I can tell from what's on my machine). So if you can use
that JRE to execute your program, instead of the "standard" one, then you may
get more information.

-- chris

Chris Uppal wrote:
> Brandon McCombs wrote:
>
>> 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?
>
> People downthread are already speculating that the problem is caused by
> modifying the model from outside the EDT; I suspect that they are correct.
>
> I just wanted to add (for general info) that the version of rt.jar which comes
> with the JRE is (at least in 1.5 and 1.6 on my machine) compiled without line
> numbers -- whence the less informative stack trace. The equivalent rt.jar
> which is part of the JRE which is inside the JDK /does/ have that information
> (again, as far as I can tell from what's on my machine). So if you can use
> that JRE to execute your program, instead of the "standard" one, then you may
> get more information.
>
> -- chris
>
>

Well I've gotten line numbers printed before but for some reason in this
case (when I really need it) the line number doesn't get printed. I've
been using the JRE included with Eclipse 3.1.2 but I just tried using
JDK 1.5 and it didn't help make line numbers visible (running it outside
of Eclipse as a regular JAR).

Nigel Wade wrote:
> Brandon McCombs wrote:
>
>
>> 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();
>> }
>> }
>>
>
> What thread is the above method being executed on? If it's not the EDT you have
> a problem there, you are modifying the JList in a thread other than the EDT.
>
> The error is telling you that when the EDT came to draw a JList it tried to
> access element 1 and that element didn't exist in the the DefaultListModel's
> Vector at the time. That would imply a synchronization error, the Vector is in
> the process of being modified whilst it's being drawn (the JList and
> DefaultTreeModel have a different idea of how many elements there are), and I
> don't see how that can happen unless it's being modified from another thread -
> even the EDT can only do one thing at a time...
>

Maybe I did this wrong but in the place in my code where I call the
method above I put the following:

SwingUtilities.invokeLater(new Runnable() {
public void run() {
list_deleteObj(); }
});

And I still get the exception generated so what am I missing?

Michael Rauscher wrote:
> Brandon McCombs wrote:
>>>>>>
>>>>>> 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(Unkno wn Source)
>>>>>> at javax.swing.plaf.basic.BasicListUI.paint(Unknown Source)
>>>> [snip]
>> 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.
>
> NB: a ListModel *is* read-only by default.
>
>>
>> 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() {
>
> Is this method called from the EDT?
>
>>
>> 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
>
> Sure, the exception originates from the UI-Delegate's paint method. Why
> would you expect the deletion not to work?
>
> The reason for the exception is usually a simple one: you're modifying
> the underlying ListModel in one thread while the EDT repaints the list.
>
> Imagine the following pseudo code as part of the painting procedure:
>
> int n = model.getSize();
> for ( int i = 0; i < n; i++ ) {
> // ...
> Object value = model.getElementAt(i);
> // ...
> }
>
> Let's consider a ListModel that contains 5 elements. The code above runs
> on the EDT, so it starts with n = 5 and enters the loop. Now, in another
> thread you delete one element from the ListModel so that
> model.getSize()==4. The loop continues until i=4, then an
> ArrayIndexOutOfBoundsException will be thrown, e.g.: 4 >= 4. If the
> second thread would have removed all elements from the ListModel, the
> exception is thrown immediately at the next model.getElementAt method
> call, e. g. 2 >= 0.


Although what you say makes sense, I wonder if it's my problem because
I'm modifying the model outside of the EDT (whatever that situation is
properly termed) and after a few other method calls is when the model is
updated with new nodes. I don't know when the exception actually occurs
(painting when the item is deleted or painting when i refresh the list
to get the current contents from the server) so maybe your theory is
still accurate.

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();
}
}

As you can see the removal from the list occurs before refresh(). In
refresh() I call expand(). In expand() I spawn the thread to refresh the
list model. If the repaint from the model.getListModel().remove(idx);
doesn't occur until my thread is spawned then maybe that creates the
exception. In another posting a few minutes before this one I tell
Nigel that I put the call to the method above on the EDT and it didn't
help; after enough deletions the exception crops up again.

Brandon McCombs schrieb:
> Although what you say makes sense, I wonder if it's my problem because
> I'm modifying the model outside of the EDT (whatever that situation is
> properly termed) and after a few other method calls is when the model is
> updated with new nodes.

If you modfy the model outside of the EDT, then it's the problem. It's
easy. Really. Don't modify UI-state outside of the EDT and you don't get
strange Exceptions

I'll explain it in more detail, e. g. have a look at

> model.getListModel().remove(idx);
> /* reload the subtree and list to show deletion */
> refresh();

Since you're using DefaultListModel, the element at index idx gets
removed from DefaultListModel's data Vector. Then, the model's listeners
(to which the JList belongs, too) get notified. The JList repaints itself.

You call refresh afterwards. I expect, you set a new Vector on the
DefaultListModel. I expect that this occurs outside of the EDT, too.


Now, I can imagine two situations:
1) remove was called while repaint was active
2) refresh() modified the ListModel while repaint was active.
E. g. refresh could call DefaultListModel#removeAll.

>
> As you can see the removal from the list occurs before refresh().

Doesn't matter. The point is, that you modify UI-state outside of the
EDT. There are only a few methods in Swing (e. g. repaint()) that may be
used outside the EDT.

Bye
Michael

Brandon McCombs schrieb:
> Nigel Wade wrote:
>> Brandon McCombs wrote:
>>
>>
>>> 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();
>>> }
>>> }
>>>
>>
>> What thread is the above method being executed on? If it's not the EDT
>> you have
>> a problem there, you are modifying the JList in a thread other than
>> the EDT.
>>
>> The error is telling you that when the EDT came to draw a JList it
>> tried to
>> access element 1 and that element didn't exist in the the
>> DefaultListModel's
>> Vector at the time. That would imply a synchronization error, the
>> Vector is in
>> the process of being modified whilst it's being drawn (the JList and
>> DefaultTreeModel have a different idea of how many elements there
>> are), and I
>> don't see how that can happen unless it's being modified from another
>> thread -
>> even the EDT can only do one thing at a time...
>>
>
> Maybe I did this wrong but in the place in my code where I call the
> method above I put the following:
>
> SwingUtilities.invokeLater(new Runnable() {
> public void run() {
> list_deleteObj(); }
> });
>
> And I still get the exception generated so what am I missing?

Look out for other threads. What does e. g. AsynchSearch do?

Bye
Michael

Michael Rauscher wrote:
> Brandon McCombs schrieb:
>> Nigel Wade wrote:
>>> Brandon McCombs wrote:
>>>
>>>
>>>> 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();
>>>> }
>>>> }
>>>>
>>>
>>> What thread is the above method being executed on? If it's not the
>>> EDT you have
>>> a problem there, you are modifying the JList in a thread other than
>>> the EDT.
>>>
>>> The error is telling you that when the EDT came to draw a JList it
>>> tried to
>>> access element 1 and that element didn't exist in the the
>>> DefaultListModel's
>>> Vector at the time. That would imply a synchronization error, the
>>> Vector is in
>>> the process of being modified whilst it's being drawn (the JList and
>>> DefaultTreeModel have a different idea of how many elements there
>>> are), and I
>>> don't see how that can happen unless it's being modified from another
>>> thread -
>>> even the EDT can only do one thing at a time...
>>>
>>
>> Maybe I did this wrong but in the place in my code where I call the
>> method above I put the following:
>>
>> SwingUtilities.invokeLater(new Runnable() {
>> public void run() {
>> list_deleteObj(); }
>> });
>>
>> And I still get the exception generated so what am I missing?
>
> Look out for other threads. What does e. g. AsynchSearch do?
>

It retrieves the current state of what the list should contain by
contacting an LDAP server. It then alerts the GUI the results are ready
by calling the GUI's updateGUI() method by I do that on the EDT like
above so it should be okay.

What I ended up doing that seems to work so far is I put the body of the
method prepareGUI() inside of the SwingUtilities.invokeLater() call.
The prepareGUI() is called by asyncSearch to prepare the GUI before the
newest results are loaded. prepareGUI() is actually what deletes the
rest of the items in the listmodel so that I don't get duplicate entries
when it is updated. I've been testing that and haven't received the
exception, yet.

Brandon McCombs wrote:
>>> And I still get the exception generated so what am I missing?
>>
>> Look out for other threads. What does e. g. AsynchSearch do?
>>
>
> It retrieves the current state of what the list should contain by
> contacting an LDAP server. It then alerts the GUI the results are ready
> by calling the GUI's updateGUI() method by I do that on the EDT like
> above so it should be okay.
>
> What I ended up doing that seems to work so far is I put the body of the
> method prepareGUI() inside of the SwingUtilities.invokeLater() call.
> The prepareGUI() is called by asyncSearch to prepare the GUI before the
> newest results are loaded. prepareGUI() is actually what deletes the
> rest of the items in the listmodel so that I don't get duplicate entries
> when it is updated. I've been testing that and haven't received the
> exception, yet.

Sounds good. Next time don't follow the trial and error method: just
ensure that any code that modifies the GUI runs on the EDT.

Bye
Michael