On Mon, 13 Oct 2025 18:22:07 GMT, Kevin Rushforth <[email protected]> wrote:
>> 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. I've replaced `Util.sleep(10)` with `fxThread.join(10)` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1934#discussion_r2428320801
