Hi Kevin, have you considered my proposal, which is basically the same approach: it uses runLater internally to dispatch the interaction with AbstractPrimaryTimer (instead of trying to make AbstractPrimaryTimer work under concurrent access).
But from the point of view of the caller, the API works just as it worked before: all state changes of the Animation class are instantly visible, there is no surprising change as it would be with what you're currently proposing. With my proposal, play() can be called on a background thread, and the behavior of the Animation class remains the same. If you're reading getStatus() after calling play(), you will always see that the animation is currently running (even if internally, the animation hasn't yet been added to the primary timer). On Thu, Jan 25, 2024 at 6:30 PM Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > > And that's why the "be careful" option is not a satisfying solution. > > Let's proceed with the option to change the implementation of > play/pause/stop/start to do the work in a runLater, and change the docs > accordingly. It's the only feasible option for JavaFX 22 (other than "do > nothing"), and I also think it is a good choice. If we later want to evolve > it for thread-safety, which I'm not convinced that we do, we can consider > that for a future release. > > -- Kevin
