On Thu, 3 Sep 2026 14:07:33 GMT, Michael Strauß <[email protected]> wrote:
> A follow-up fix that would address the lock-order problem at its core, rather > than special-casing the callback method, would be to give the Java timer an > explicit lifecycle: STOPPED-> RUNNING-> STOPPING-> STOPPED. I could add this to the follow-up issue as a possible way to address the deadlock, as long as it doesn't require changes to the native Timer code on the various platforms. Given that the Timer class is not public API, we will likely choose to revise the documentation rather than require the implementation to match the current state of the Timer docs. My plan is to reduce the internal API and implementation to what we actually need. Here are the things I plan to address in a follow-up issue: * Explicitly disallow `start()` and `stop()` while in a callback. Allowing self-cancellation complicates the design for no good reason. * Consider explicitly disallowing implicit restart (that is, calling `start()` while running). * Consider whether to allow `start()` again following a successful `stop()`. * Fix the deadlocks that are possible if `Timer.isRunning()`, `Timer.pause()` or `Timer.resume()` are called from a callback concurrently with an in-progress stop. This will likely fix [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) and allow us to remove the `WinTimer` overrides of the `pause()` and `resume()` methods added by this PR. * Change the docs as follows: - Remove the advice to call `invokeAndWait()` - Document that callbacks should avoid blocking calls and must not call `start()` or `stop()` - Remove stale docs about overriding `run()` since there is no such method - Document the restrictions on `start()` decided above ------------- PR Comment: https://git.openjdk.org/jfx/pull/2290#issuecomment-5592850783
