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

[Michael Strauß]

Note: this proposal does NOT allow Animation.play/stop/etc. to be
"called on any thread" as mentioned in JDK-8324658 [0].

It merely removes the requirement that these methods must be called on
the FX thread, but this doesn't make the class inherently thread-safe.
That is an important distinction to proposals that call for posting
the play/stop calls directly to the FX thread.


[0] https://bugs.openjdk.org/browse/JDK-8324658


On Wed, Jan 24, 2024 at 10:30 PM Michael Strauß <michaelstrau2 at gmail.com> wrote:
>
> Here's another option, which I have implemented as a proof of concept [0]:
>
> The play/stop/etc. methods are currently specified to be
> "asynchronous". This language should be removed, such that the methods
> will be implied to execute synchronously from the point of view of the
> caller (like every method that doesn't specify anything to the
> contrary).
>
> All changes to observable state will remain instantly visible for the
> calling thread. However, internally, interactions with
> AbstractPrimaryTimer are posted to the FX thread if necessary. This is
> not an unsurprising change, since the callback from the FX thread was
> always occuring at an unspecified time in the future.
>
> To make this work, AbstractPrimaryTimer::pause/resume/nanos will have
> to be synchronized to ensure field visibility across threads.
> In the Animation class, interactions with AbstractPrimaryTimer will be
> encapsulated in the new nested class AnimationPulseReceiver, which
> also deduplicates redundant interactions with AbstractPrimaryTimer.
> For example, repeatedly calling start() and stop() in quick succession
> may require just a single interaction with AbstractPrimaryTimer in the
> future (if we ended up in the running state), or no interaction at all
> (if we ended up in the stopped state).
>
>
> [0] https://github.com/openjdk/jfx/pull/1349