On Fri, 22 Mar 2024 21:45:36 GMT, Alexey Ivanov <aiva...@openjdk.org> wrote:
>>>Instantiating JFileChooser on EDT adds complexity for no benefit. The >>>JFileChooser is still accessed concurrently from several threads, including >>>Swing internal thread. >> >> But still, this is a common requirement to create UI components on EDT, and >> that will replicate more or less how it will work in the application. > >> > Instantiating JFileChooser on EDT adds complexity for no benefit. The >> > JFileChooser is still accessed concurrently from several threads, >> > including Swing internal thread. >> >> But still, this is a common requirement to create UI components on EDT, and >> that will replicate more or less how it will work in the application. > > And it is a common requirement ***not** to call > `fileChooser.rescanCurrentDirectory` concurrently* in 5 different threads. So > it does not apply. In general, I agree all Swing components are to be created and accessed on EDT. However, there are cases where instantiating and testing is safe on main thread. It is when the component is not shown on the screen, its state does not depend on any events dispatched by the event queue. There are such tests in the JDK code base. I think this test is one of such cases where `JFileChooser` can be (safely) created on the current thread. The test does not display the file chooser, its state does not depend on receiving input events and handling them. Essentially, the test verifies that *the implementation of `JFileChooser.rescanCurrentDirectory` is thread-safe*. It wasn't. Two bugs were resolved to make the implementation thread-safe: [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670) and [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18109#discussion_r1541975141
