On Fri, 29 Mar 2024 02:00:18 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
> > However, there are cases where instantiating and testing is safe on main > > thread. > > That is my point, make it less safe - when the component is created on one > thread:EDT and then for some reason accessed on a different thread, the > rescanCurrentDirectory should still work. I got your idea! However, I still see no benefit for doing it. Yes, when `JFileChooser` is instantiated, it creates its UI delegates and the default model, `BasicDirectoryModel`. The constructor of the model calls `validateFileCache` which starts the background thread and will update `fileCache`. It does not make the initialisation less thread-safe: the same two threads are involved — `FilesLoader` and EDT. Yet there's no race yet… The `ConcurrentModificationException` is thrown when the background `FilesLoader` is iterating over `fileCache` while EDT runs `DoChangeContents.run` which adds elements to `fileCache` or removes elements from it. By the time the `Scanner` threads start, a race becomes possible. If the initial `FilesLoader` completes and posts the `DoChangeContents` object to EDT, the `FilesLoader` threads created by the scanners will race… but `fileCache` is empty initially, thus iterating over it is very quick. Therefore getting `ConcurrentModificationException` is unlikely until `fileCache` contains a list of files. This state is reached later in the timeline of the test. The initial `FilesLoader` thread that's started when `JFileChooser` is instantiated plays a role too… Yet it's running concurrently with the `Scanner` threads whether the `JFileChooser` object is created on the current thread or on EDT. --- Taking the above into account, instantiating `JFileChooser` on EDT adds complexity to the test but brings no benefits. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18109#discussion_r1544825191
