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

Reply via email to