On Tue, 19 Mar 2024 01:08:25 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> I don't think it matters here⦠The test does not rely on even processing on >> EDT, no state of `JFileChooser` is modified except for calling >> `rescanCurrentDirectory`. Technically, I am not allowed to do so either. But >> if I call `rescanCurrentDirectory` from EDT only, the test becomes void. > > I think it will fire the property change events via firePropertyChange from > the constructor and it is better to do that on EDT. I guess it does fire property change events on the current thread rather than EDT in this case. I still don't think it matters in this case. After the `JFileChooser` is created, it is accessed on the Scanner threads only, and only to call its `rescanCurrentDirectory` method. This call, in its turn, creates a new background thread which accesses the fields and methods of `JFileChooser` as well as `FileSystemView`. Instantiating `JFileChooser` on EDT adds complexity for no benefit. The `JFileChooser` is still accessed concurrently from several threads, including Swing internal thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18109#discussion_r1530766002