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

[Jurgen Doll]

Thanks for the heads-up Kevin,

I gave it a spin and found that generally because I use Task to load my  
fxml views I had problems.

Some of these I could resolve by wrapping the offending line with runlater  
in the fxml initialise method. This reminded me though of the days when  
Tooltips had to be wrapped as well and it felt wrong because generally a  
view may be constructed and modified on any thread as long as it's not yet  
attached to a Scene in a Window that is showing.

This is highlighted further because I also have some third party controls  
and libraries that are being initialized as part of the view, which now  
just crash my application. This means that I cannot instantiate these  
controls or libraries on any thread I want but have to make sure its done  
on the FX thread, even though they're not attached to a Scene yet.

As a possible solution I was wondering since the Animation API says that  
calls to play() and stop() are asynchronous if it wouldn't then be valid  
to instead of throwing an exception, if the call to it isn't being made on  
the FX thread, that it rather be delegated to the FX thread with for  
example something like:

public abstract class Animation {
     public void play() {
         if ( Platform.isFxApplicationThread() ) playFX();
         else Platform.runLater( () -> playFX() );
     }

     private void playFX() {
         // previous play() code
     }
}

This would then prevent the NPE errors that sometimes occur but not put a  
burden on the existing code in the wild and allow views to be loaded with  
Task call() without worries.

Thanks, regards
Jurgen


  On 8/18/2023 4:17 PM, Kevin Rushforth wrote:
> As a heads-up for app developers who use JavaFX animation (including  
> Animation, along with any subclasses, and AnimationTimer), a change went  
> into the JavaFX 22+5 build to enforce that the play, pause, and stop  
> methods must be called on the JavaFX Application thread. Applications  
> should have been doing that all along (else they would have been subject  
> to unpredictable errors), but for those who aren't sure, you might want  
> to take 22+5 for a spin and see if you have any problems with your  
> application. Please report them on the list if you do.
>
> See JDK-8159048 [1] and CSR JDK-8313378 [2] for more information on this  
> change.
>
> Thanks.
>
> -- Kevin
>
> [1] https://bugs.openjdk.org/browse/JDK-8159048
> [2] https://bugs.openjdk.org/browse/JDK-8313378