On Mon, 13 Oct 2025 17:22:08 GMT, Johan Vos <[email protected]> wrote:
>> Better, sure, but it isn't always possible in practice. There are times >> where a delay is still needed. >> >> This test now waits for the lock on the condition that will lead to the >> thread shutting down. Good. It's still necessary to sleep for a small time >> to be sure that it has. > > As I said in my previous comment, I don't see this as a showstopper for this > PR, but since it might help in general, I keep thinking about approaches to > remove the sleep. > Wouldn't it be an option here to obtain the JavaFX Application Thread after > the `assertTrue(Platform.isFxApplicationThread());` and assign it to e.g. > `Thread fxThread` so that instead of the `Util.sleep` we can do > `fxThread.join(10)` ? (I might be missing something though) Yes, something like what you describe might work in this case. As for the more general problem, which goes well beyond this PR, there are many places in our tests where we do need sleeps. They fall into two cases 1. Lack of a feature that provides a deterministic way to know when something has occurred. Implementing the missing functionality could allow us to replace sleeps with something more deterministic. 2. Inherent limitations where there cannot be a deterministic way to know when something has occurred. Many, if not most, of the instances of 1 could be addressed with an implementation of `Robot::waitForIdle`. It's a long-standing feature request. It's not rocket science to implement, but isn't trivial either. Most of the instances of 2 are due to either A) platform delay in realizing certain window system operations (show/hide/minimize/maximize/to-front/etc); or B) inherent GC non-determinism. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2427030820
