On Thu, 16 Mar 2023 04:33:46 GMT, Prasanta Sadhukhan <[email protected]> wrote:
> As per java/util/ConcurrentModificationException spec > > `this exception does not always indicate that an object has been concurrently > modified by a different thread. If a single thread issues a sequence of > method invocations that violates the contract of an object, the object may > throw this exception. For example, if a thread modifies a collection directly > while it is iterating over the collection with a fail-fast iterator, the > iterator will throw this exception. ` > > so we should also see the sequence of operations on `fileCache` As per the exception log, we see at java.base/java.util.AbstractList.equals(AbstractList.java:544) at java.base/java.util.Collections$SynchronizedList.equals(Collections.java:2453) at java.desktop/javax.swing.plaf.basic.BasicDirectoryModel$FilesLoader$1.call(BasicDirectoryModel.java:358) where we have https://github.com/openjdk/jdk/blob/42dd9077a087e1431b76c5653db820e65a6cc177/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java#L352-L355 ie it is trying to get the element from same index twice, not sure if it's an issue but can be optimised to get it once (maybe a small testcase can be run in linux having 100's of file objects and try to get the same element multiple times to see if it returns ConcurrentModificationException) ------------- PR: https://git.openjdk.org/jdk/pull/13012
