HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE

[Michael Strauß]

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.rushforth at 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