0

I have a code which sets the active selection of the ESelectionService when the user selects something in the tree. Like here:

treeViewer.addSelectionChangedListener(new SelectionChangedListener() {
    @Override
    public void selectionChanged(SelectionChangedEvent event) {
        if (selectionService != null) {
             selectionService.setSelection(((IStructuredSelection) event.getSelection()).getFirstElement());
        }
    }
});

where selectionService is being injected. So far so good.

I also have some command handlers with their own canExecute() methods. In these methods I check the current selection (which is also being injected) and decide if the canExecute() method should return true or false. What I also do in this method is, I also change the visibility of the corresponding HandledToolItem - like here https://stackoverflow.com/a/23602909/2097228.

Now what I experience is that sometimes the call to the setSelection method of the ESelectionService throws a ConcurrentModificationException. This actually occurs when the ToolItemUpdater accesses the itemsToCheck ArrayList.

Is my approach error-prone or is this just a bug in 4.4?

Here is the stacktrace:

Exception occurred
java.util.ConcurrentModificationException
        at java.util.ArrayList$Itr.checkForComodification(Unknown Source)
        at java.util.ArrayList$Itr.next(Unknown Source)
        at org.eclipse.e4.ui.workbench.renderers.swt.ToolItemUpdater.updateContributionItems(ToolItemUpdater.java:36)
        at org.eclipse.e4.ui.workbench.renderers.swt.ToolBarManagerRenderer$8.changed(ToolBarManagerRenderer.java:367)
        at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:110)
        at org.eclipse.e4.core.internal.contexts.EclipseContext.processScheduled(EclipseContext.java:338)
        at org.eclipse.e4.core.internal.contexts.EclipseContext.set(EclipseContext.java:352)
        at org.eclipse.e4.ui.internal.workbench.swt.E4Application$4.changed(E4Application.java:842)
        at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:110)
        at org.eclipse.e4.core.internal.contexts.EclipseContext.processScheduled(EclipseContext.java:338)
        at org.eclipse.e4.core.internal.contexts.EclipseContext.set(EclipseContext.java:352)
        at org.eclipse.e4.ui.internal.workbench.SelectionAggregator$7.changed(SelectionAggregator.java:228)
        at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:110)
        at org.eclipse.e4.core.internal.contexts.EclipseContext.processScheduled(EclipseContext.java:338)
        at org.eclipse.e4.core.internal.contexts.EclipseContext.set(EclipseContext.java:352)
        at org.eclipse.e4.ui.internal.workbench.SelectionServiceImpl.setSelection(SelectionServiceImpl.java:31)
        at com.e4test.parts.SamplePart$TreeViewerSelectionListener.selectionChanged(SamplePart.java:116)
Community
  • 1
  • 1
Anton Sarov
  • 3,712
  • 3
  • 31
  • 48
  • A stack trace of the exception might help – greg-449 Jan 26 '15 at 13:14
  • @greg-449 I edited the post - now with stack trace attached – Anton Sarov Jan 26 '15 at 13:24
  • Looks like you are managing to change the 'items to check' list in the ToolItemUpdater while it is iterating through that list. Probably in your 'HandledToolItem' 'canExecute' method - show us that code. – greg-449 Jan 26 '15 at 14:10
  • Yes, this is what I thought, too. My `canExecute` method only checks the type of the selection (simple instanceof check) and then calls the `setToolItemVisible` method - which is as I pointed out in my question. So it is the setToolItemVisible method that is actually causing the troubles - editing the items which are still referenced by the ToolItemUpdater – Anton Sarov Jan 26 '15 at 14:18
  • You did keep the Display.asyncExec call in setToolItemVisible? That looks like it is trying to delay the set visible until after the loop completes. – greg-449 Jan 26 '15 at 14:33
  • I think this caused the problem. One of the handlers had Display.syncExec call. At least the exception is not reproducible anymore. Thanks – Anton Sarov Jan 28 '15 at 11:09

0 Answers0