Community
Participate
Working Groups
I20100720-0800, has been like this forever I ran the Infer Generic Type Arguments refactoring and left the preview open for > 30 minutes. When I tried to continue and apply the changes, I got the ConcurrentModificationException below. Initial changes should not be DynamicValidationStateChanges that throw away their children. Only undo changes should clean up after a while. Fix idea: Add a new constructor to DynamicValidationStateChange that prevents cleanup for that change (but implements it for Undo/Redo changes). java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.remove(AbstractList.java:357) at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:297) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.access$0(DynamicValidationStateChange.java:1) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange$1.run(DynamicValidationStateChange.java:98) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4777) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.perform(DynamicValidationStateChange.java:101) at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278) at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:258) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306) at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.executeChange(UIPerformChangeOperation.java:92) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:223) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Rajesh, can you please have a look? We need to keep the clearing of children in the Undo case, since refactoring changes can be big, and they would otherwise be around for too long. To avoid having to change all clients, please change the default behavior such that children are not cleared, and add a new (private) constructor that is only used from createUndoChange(..).
I couldn't reproduce the original problem any more. I reduced DynamicValidationStateChange#LIFE_TIME and tried to provoke resource changes (e.g. by enabling auto-refresh and changing a file in an external editor), but never got the ConcurrentModificationException. Closing for now (without taking any action).
*** Bug 383080 has been marked as a duplicate of this bug. ***
Michael, do you remember anything unusual about the execution of the refactoring? Did you click the Preview button and then leave the computer unattended for > 30 minutes? Or did a build take place in the background?
The refactoring didn't use more than 5 minutes, until it failed. I am not sure that I didn't leave a preview open for more than 30 minutes on that day, but I don't think so. Maybe it could be because I was moving packages to a subpackage. My Idea behind this is that: (Of course this is not eclipse) When I do something like this at the bash shell, I get this: $ mkdir subdir $ mv * subdir/ mv: cannot move `subdir' to a subdirectory of itself, `subdir/subdir' Maybe subdir was selected unintentionally (maybe even internally in eclipse?) when moving to it? Or maybe eclipse depends on something in the directory to stay constant while doing the move, maybe this won't happen when moving to another package which is not a subpackage of the current location. Maybe eclipse will move something to the subdirectory while it is contained in a list which is currently iterated. About building: I have "Build automatically" activated, but I don't think (but don't know sure) that eclipse was building in that time.
I still can't explain why a workspace change notification can occur while a refactoring dialog is open. The workspace should be locked at that time. Anyway, it's not too hard to avoid premature deletions of changes, so I just implemented that. Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=8e2605d3dff4c11b7a58ad084d4d7aa400f2c023
Hmmm, it seems that the above link does not work: Cannot connect to git.eclipse.org
> Cannot connect to git.eclipse.org Yeah, I heard the eclipse.org webserver had intermittent connection problems over the weekend. Should be back to normal now.
