AnimateFX: named JavaFX animations with a playOnFinished chain that stops cleanly

A preset animation library for JavaFX, borrowed from CSS

AnimateFX is described as a library of more than seventy ready-to-use animations for JavaFX, and the README describes it more briefly as a library of ready-to-use animations for JavaFX.

The lineage is stated in the credits: the animations are inspired by the Animate.css project by Dan Eden. That is the important design fact. Animate.css is a set of named CSS keyframe effects with CSS easing curves, and AnimateFX is that vocabulary translated into JavaFX objects. The names are familiar in a way that makes the library easy to browse, and the timing feels like web animation because it was derived from web animation.

The audience is a JavaFX application developer who wants a transition without writing a Timeline and an interpolator by hand. That is a common problem in desktop UI work, where a handful of effects, fade, slide, bounce, zoom, are needed in a dozen places and each one is tedious to author correctly.

The repository layout matches a small library with a demo attached: an animatefx/ directory for the library, an animatefx-demo/ module for the demo application, a build.gradle and settings.gradle for the build, publish-root.gradle for publishing, and the Gradle wrapper scripts. The features list in the README names four things: custom animations, custom interpolators, play and stop of an animation, and playing one animation after another, with a note that more is to come.

Two ways to use it: constructed immediately, or configured before the node exists

The quick start shows the simple case, where the animation is created with its target and started straight away.

Text text = new Text("AnimateFX");
new Bounce(text).play();

The interesting case is the second one. The README describes ready-to-use animations, including visual modifiers like GlowBackground and GlowText, as safely instantiable using alternate or parameterless constructors and configurable lazily using builder-friendly setters before binding a Node.

GlowBackground glow = new GlowBackground(myRegion.getBackground())
    .setColorA(Color.WHITE)
    .setColorB(Color.YELLOW)
    .setColorSteps(20);

// Set the node later in the UI lifecycle
glow.setNode(myRegion);
glow.play();

That pattern exists because of how JavaFX UI code is often written. A background or a text effect frequently has to be created while a region is still being assembled, before the region exists, and only bound afterwards. An API that requires the target node in the constructor forces the caller to either reorder their UI code or build the effect twice. The builder setters return the object so they can be chained, and setNode comes later, so the effect can be configured once and bound once.

The trade-off is that the library now has two lifecycles for its effects, the immediate one and the deferred one, and the deferred path is where a mistake hides. A glow that is configured but never given a node has nothing to animate, and the README does not describe what happens in that case.

playOnFinished chains animations, and stop() kills the whole chain

The chaining API is the part of AnimateFX that goes beyond a preset effect, and the README gives it an explicit safety guarantee.

Text text = new Text("AnimateFX");

// When Bounce finishes naturally, BounceIn will play
new Bounce(text).playOnFinished(new BounceIn(text)).play();

The chain is built by handing one animation to another before starting the first, so BounceIn begins when Bounce finishes naturally.

The guarantee is about what happens when the chain is interrupted. The README states that chained animations are fully manual-stop safe: if you call .stop() on the parent animation, the chain will halt completely rather than incorrectly launching subsequent animations.

That is a small sentence with a large amount of engineering behind it. The failure mode it rules out is the obvious one. If the completion callback fires when the animation is stopped rather than when it ends, then a user who cancels a dialog transition would trigger the entrance animation of the next screen as well, and the UI would animate itself while the user is trying to dismiss it. The README frames the guarantee as being about manual stops specifically, which implies the completion hook is shared between natural end and interruption, and that the library distinguishes the two.

For a library of this size, having that behaviour documented and guaranteed is a reasonable signal about the care in the rest of the code, and it is also the first thing to test against your own JavaFX version.

Published to Maven Central, with a snapshot repository behind it

The dependency is declared in the standard way, and the README gives both build systems.

For Gradle, with the java and java-library plugins:

plugins {
    id 'java'
    id 'java-library'
}

dependencies {
    implementation 'io.github.typhon0:AnimateFX:1.3.1'
}

For Maven:

<dependency>
  <groupId>io.github.typhon0</groupId>
  <artifactId>AnimateFX</artifactId>
  <version>1.3.1</version>
</dependency>

The group id io.github.typhon0 with an uppercase artifact id AnimateFX is the shape of a JitPack-style coordinate, and the Maven Central badge in the README says the artifact is published there. The javadoc badge points at javadoc.io for the same coordinates.

Snapshots are handled separately, through the Sonatype OSS snapshot repository. The Gradle form adds the repository URL and then depends on 1.3.1-SNAPSHOT, while the Maven form adds the same repository block and the same snapshot version.

repositories {
    maven { url 'https://oss.sonatype.org/content/repositories/snapshots/' }
}

dependencies {
    implementation 'io.github.typhon0:AnimateFX:1.3.1-SNAPSHOT'
}

One discrepancy to check before you pin anything. The README tells you to depend on 1.3.1, while the newest release tag visible in the repository is 1.3.0, published on 2024-06-08, with 1.2.3 from 2022 and 1.2.2 from 2020 before it. Either a 1.3.1 was published to Maven Central without a matching GitHub tag, or the README refers to a version that has to be checked before it resolves.

Compiled for Java 11 but built on Gradle 8.7 and JDK 21

The compatibility section is where this README is unusually precise, and it is worth reading closely because Java projects often leave this implicit.

The build system line says the project is built and compiled using Gradle 8.7 under modern JDK 21 environments. The Java compatibility line says it is compiled targeting Java 11 (LTS), that it is 100% backward compatible, and that it is fully supported to run on all modern Java and JavaFX versions, including Java 11, 17, 21, and 25 and later LTS releases.

So the bytecode floor is Java 11 even though the toolchain is newer. That combination is deliberate and useful: it means an application still on Java 11 can depend on the library, while the maintainer builds with a current JDK and modern Gradle. The installation section also lists Gradle 8.x and 7.x as the supported consumer build tools, so the library's own build version does not constrain yours.

The headless line is the one that saves you a headache. The README states that the project is completely safe to compile and build on headless or JRE-only runtimes, such as Docker containers, that lack native display interfaces. JavaFX historically ties itself to the windowing system at start-up, and many JavaFX libraries are therefore unbuildable or untestable in a container. A library that is deliberately buildable without a display is easier to include in a containerised build pipeline, and the README also lists a JFXCentral badge, which is the directory for JavaFX libraries that suggests this library is discovered by JavaFX developers rather than only by its author.

Where a JavaFX preset library is the wrong choice

Three limits are structural.

The first is the platform. This is a JavaFX library. It does nothing for a browser, for Android, or for a Swing application, and there is no second rendering backend in the repository. If your team is not building JavaFX, none of this applies.

The second is the vocabulary. Because the animations are inspired by Animate.css, they inherit CSS timing and easing conventions. That is a strength if you are porting a design from the web, and a limitation if your product has an established motion language of its own. There is no documentation in the README about the easing curves, the durations, or how a Bounce is parameterised, so matching an existing design system means reading the source.

The third is version discipline. The last push was on 2026-05-29, the newest release tag is 1.3.0 from 2024-06-08, and the README asks you to use 1.3.1. A library whose documented version and its tagged version disagree is a small sign of a project maintained in the gaps rather than on a release schedule, and the feature list ends with a note that more is to come, which is a promise rather than a plan.

There is also the question of what you are really buying. Seventy animations are seventy Transition objects with easing curves, which is a modest amount of code that any competent JavaFX developer could write for the three effects they actually need.

Hand-written Timelines versus a preset library

The alternative is not another library, it is the JavaFX animation API itself, used directly.

A Timeline with a KeyValue and a KeyFrame is the primitive every AnimateFX animation is built from, and writing one by hand gives you exact control over duration, interpolator, delay and the target property. For a single bespoke transition in an application with a defined motion spec, that is often less work than adopting a dependency, because the alternative to adopting the library is not nothing, it is twenty lines of code you own.

The difference in approach is defaults versus control. A preset library is a catalogue of good-looking effects that behave consistently, so a designer can ask for Bounce and get the same result in every screen. Direct Timeline code is a specification you implement, so every screen can behave differently and every transition is yours to test.

The middle ground is to take the two or three effects you use everywhere from a library, write the rest by hand, and keep the animation code in one place in your codebase. That is the shape AnimateFX is best at, since its chain API and its builder-friendly effects are the parts that would otherwise be tedious to reimplement, and its seventy-odd catalogue entries are the parts you will probably not all need.

A note on the comparison itself: the credits point at Animate.css, so a web developer who already knows that vocabulary will find the naming familiar, while a developer who has never seen it will be reading the class names to find out what is available.

Editorial conclusion

AnimateFX fits a JavaFX desktop application that needs a set of polished transitions without hand-written Timeline code, especially one that has to build effects before the node they decorate exists. It does not fit a web front end, a mobile client, or a team that needs its own animation vocabulary, since the timing and easing conventions come from CSS. Verify first that the 1.3.1 artifact the README names is actually resolvable from Maven Central, because the newest release tag in the repository is 1.3.0, and confirm that the animations you plan to use keep their semantics on the JavaFX version your application ships with.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. Typhon0/AnimateFX on GitHub