DEV Community: Frank Delporte

Debugging BentoFX in MelodyMatrix with Matt Coley, Scenic View, and an Honest Look at AI-Generated Code

Frank Delporte — Tue, 21 Apr 2026 10:01:21 +0000

There are bugs you can solve by yourself, and bugs where you just need to sit down with someone who knows the internals. This video is in the second category. MelodyMatrix uses BentoFX for its dockable panel layout. Branches, leaves, tabs on the side, content panels that open and close. It works well until something fights the layout. But I had some visual problems I could not explain, some code that felt more complicated than it should be, and no good explanation for why.

When Your Layout Library Misbehaves, Call the Person Who Wrote It

So I asked Matt Coley if he had time to take a look. Matt is the creator of BentoFX, but he is also known for Recaf, a bytecode editor for Java that itself uses BentoFX heavily as its UI framework. That means when Matt looks at a BentoFX integration. He wrote the library and uses it heavily in his own project. If you want the full background on his work, there is an earlier interview: JavaFX In Action #22 with Matt Coley.

What BentoFX Actually Does

BentoFX is a docking and layout library for JavaFX. The core idea is that you have a tree of containers: branches split the space horizontally (or vertically if you rotate them), and leaves hold the actual content. Tabs let you stack multiple panels in one leaf.

In MelodyMatrix, this maps to a sidebar on the left, a main content area in the middle, and additional panels on the right. It is a clean model when you understand it, but there are some behaviors that are not immediately obvious. Pruning is one of them: when you close a panel, BentoFX removes the empty container and reorganizes the remaining branches. That is usually what you want, but if you are also managing widths or visibility yourself in code, things start to conflict. That was part of my problem.

Scenic View: Browser DevTools for JavaFX

This session reminded me that Scenic View exists and I should have been using it much earlier.

If you have done any web development, you know how useful browser inspect tools are. You hover over an element, you can see exactly what CSS is applied, what the padding is, why something is shifted by 12 pixels. Scenic View does the same thing for a running JavaFX application. It attaches to your running application and shows the scene graph live with all the layout properties.

We pulled it during the video to look at the tab header rotation issue I was having. Instead of guessing which CSS rule was causing the offset, we could see exactly what was happening in the layout tree. Embarrassingly, I had not used it before this session. It should be in your JavaFX debugging toolkit!

Some Honest Thoughts on AI-Generated Code

We also spent some time looking at code that had been written or modified by Claude and Copilot. Matt spotted it quickly: the code had the patterns you recognize after reviewing AI-generated output. The rotation fix for the tab headers was one example. The code did technically work, but it was fragile: it used CSS class lookups that would break if BentoFX changed anything internally. Matt's take was pragmatic: if it works now, and you have a way to update it when it breaks, fine. But it is worth knowing that is what you are dealing with.

The broader cleanup was straightforward once Matt explained how BentoFX manages its own leaf widths. I had added animation and width-tracking code essentially fighting the library. Removing it simplified things considerably and fixed one of the issues in the process. Not all AI-generated code is bad. But a code review from someone who knows the library beats prompting your way through it. This session was a good reminder of that.

We Might Have Found a Bug

BentoFX did something unexpected with divider modes when re-opening a panel that had been closed. Matt looked at his own source and said he suspected something was not right there. It is a 0.x library, but it is actively maintained and used in production in Recaf. Matt's response was immediate: file a ticket with reproduction steps.

Timeline

00:00 Introduction: Matt Coley, Recaf, BentoFX
02:19 How BentoFX is used in MelodyMatrix
04:18 Visual problems with the BentoFX integration
06:33 A look into the MelodyMatrix code
09:15 Changing tab position from top to side, and why the project uses Kotlin
16:25 Using Scenic View to debug a JavaFX layout live
22:38 How pruning affects visual BentoFX components
34:53 Cleaning up unneeded code: let BentoFX handle leaf widths, removing animations
41:33 We probably found a bug in BentoFX, and a look into the BentoFX source

Testing Lottie4J JavaFX Animations in GitHub Actions Without a Display: JavaFX 26 Headless to the Rescue

Frank Delporte — Mon, 20 Apr 2026 06:44:35 +0000

When I released Lottie4J 1.1.0, I mentioned something a bit embarrassing in the release notes and this blog post: there was a new unit test to compare the JavaFX player output against a JavaScript reference player, but it "can not run on CI, because it requires a display output." A TODO. A known limitation. One of those notes you write hoping future-you will figure it out.

JavaFX 26 was released on March 17, 2026 and includes a new headless platform, allowing me to get the test running on GitHub Actions without a display.

The Test, and Why It Mattered

The core challenge with Lottie4J is correctness. The Lottie format is complex with a lot of nested data, and my JavaFX renderer has to produce output that matches what a JavaScript player would show. Pixel-perfect is too ambitious, but "is this a close enough match" is a reasonable bar.

During development, I use a separate application within the Lottie4J project: LottieFileDebugViewer. This is a JavaFX application that loads a Lottie file and renders it both with the JavaFX player, and inside a Webview with the official Lottie player. This makes it easy to compare the result and debug differences by diving into the data structure and different layers.

Based on this debug viewer, I created a unit-test approach with two steps:

A WebViewScreenshotGenerator that I run once on my developer machine. It loads each animation in a JavaFX WebView using the LottieFiles JavaScript player, and captures screenshots of specific frames. These are the reference images and are committed to the repo.
The unit test CompareFxViewWithWebViewTest then renders the same animations with the Lottie4J JavaFX player, takes screenshots at the same frames, and compares pixel data against the references.

The reference images are generated once and committed. The test just checks that the JavaFX output stays consistent with them. If something breaks in the renderer, the test will catch it.

This was all working fine locally. The problem was GitHub Actions. The CI runner has no display and no graphics stack. So I disabled this test for CI with:

@DisabledIfEnvironmentVariable(named = "CI", matches = "true")

What Changed in JavaFX 26

JavaFX 26 added a Headless Platform Prototype built directly into the javafx.graphics module. No extra dependencies, no native libraries, no Monocle setup. You pass a single JVM flag:

-Dglass.platform=headless

That is it. JavaFX starts up, you get a functional toolkit, you can create scenes, render nodes, take snapshots, and run animations, all without a display attached. The Gluon team did the heavy lifting on this for JavaFX 26, and it makes CI testing of JavaFX components much more practical. The flag works the same way as running your application normally. The difference is that there is nothing being drawn to a screen. For testing purposes, that is exactly what you want. It also opens the door to server-side rendering, for example, to generate a snapshot of a UI component without a display.

The Catch: JavaFX 26 Requires Java 24

Lottie4J targets Java 21 and JavaFX 21. That is the LTS version most projects are still running on. As this version is widely adopted, I don't want to force users of the library to jump to a newer version just because I want fancier test infrastructure. So the main project stays on 21 (for now).

But JavaFX 26 requires Java 24 or higher to run. They bumped the compiled bytecode level to --release 24 in this release, so if you try to use it with an older JDK you get an error immediately. This means the test infrastructure has to use a different Java and JavaFX version than the main build. The solution I landed on was a Maven profile in the root pom.xml that overrides both version properties and configures the surefire plugin:

<profile>
    <!-- Activates JavaFX 26 headless windowing for unit tests in CI. -->
    <!-- Usage: mvn test -Pheadless-tests -->
    <id>headless-tests</id>
    <properties>
        <java.version>25</java.version>
        <javafx.version>26</javafx.version>
        <surefire.argLine.headless>
            -Dglass.platform=headless --enable-native-access=javafx.graphics
        </surefire.argLine.headless>
    </properties>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.0.0-M5</version>
                <configuration>
                    <argLine>
                        --add-opens com.lottie4j.fxfileviewer/com.lottie4j.fxfileviewer=ALL-UNNAMED
                        -Dglass.platform=headless --enable-native-access=javafx.graphics
                    </argLine>
                </configuration>
            </plugin>
        </plugins>
    </build>
</profile>

When this profile is active, Maven bumps java.version to 25 and javafx.version to 26, so the dependency resolution picks up JavaFX 26 for the test classpath while the main source still compiles to Java 21 targets. The surefire plugin then passes two JVM arguments to the test JVM:

-Dglass.platform=headless tells JavaFX to use the new headless glass backend instead of trying to connect to a display.
--enable-native-access=javafx.graphics is required because the headless platform uses native code paths that the Java module system would otherwise block.

The --add-opens line gives the test runner access to the fxfileviewer module internals it needs to load and compare the rendered output.

The fxfileviewer/pom.xml and fxplayer/pom.xml pick up the overridden javafx.version property through normal Maven inheritance, so those modules automatically get JavaFX 26 on the test classpath when the profile is active.

The GitHub Actions Side

The Maven workflow sets up the environment with a Java 25 JDK so the JavaFX 26 runtime can load, and invokes Maven with the profile:

mvn test -Pheadless-tests

The rest of the build still compiles against Java 21 targets, so the library artifact itself is not affected. The profile only kicks in for the test run. The workflow does not need any display setup, no Xvfb, no DISPLAY environment variable tweaks. The headless flag handles all of that!

What This Actually Tests

The unit test compares screenshots of Lottie animations rendered by the JavaFX player against the pre-generated reference images from the JavaScript player. It loads a set of known animation files, renders specific frames from each one, takes a snapshot using WritableImage and SnapshotParameters, and then does a pixel-level comparison with a configurable tolerance.

The result is a regression test that runs on every push. If someone changes the rendering logic in a way that visibly breaks an animation, CI will catch it. This is more useful than it sounds, because Lottie rendering involves a lot of layered transformations, easing functions, and shape operations where subtle bugs are easy to introduce.

Would I Recommend This Pattern?

Yes, with some caveats.

The version juggling is real work. If you want to use JavaFX 26 headless for testing while keeping your library on an older Java version, you need to be careful about separating the test JVM configuration from the main build. Maven makes this doable but not exactly elegant.

The reference image approach also requires discipline. The references need to be generated consistently, ideally on a reproducible setup, and you need to think about what tolerance makes sense for your comparisons. Too strict and you get flaky tests. Too loose and you miss real regressions.

But the payoff is real. The test that I had marked "can not run on CI" now runs on CI. No virtual framebuffer, no Docker tricks, no manual intervention. JavaFX starts up, renders the animations, and the comparison happens cleanly.

For any library that does visual rendering in JavaFX, this is the kind of testing infrastructure that was genuinely missing before. Good work, OpenJFX contributors!

Links:

MelodyMatrix V1.0.0 Released: Shipping a JavaFX App with jDeploy, GitHub Actions, and Auto-Update

Frank Delporte — Thu, 16 Apr 2026 09:57:28 +0000

Some side projects take a while to get to a proper release. MelodyMatrix is one of those. The app has been downloadable for quite some time thanks to jDeploy, but there was no official V1.0.0 yet. No tagged release. No moment of "okay, this is it." Just a rolling build on every commit to the main branch.

That changed now: live, on camera, together with Steve Hannah, the creator of jDeploy.

What Is MelodyMatrix?

MelodyMatrix is a JavaFX application for musicians. It connects to MIDI devices, lets you practice and record, and has a set of views that help you understand what you are playing. Those views are open source and available on GitHub. The full app is free, but has some features that are only available with a license. The download packages are published via GitHub Releases.

Building it has been a long journey. JavaFX, MIDI, and musical theory in one app, keeping it working across Windows, macOS, and Linux, while also building and distributing it automatically from GitHub Actions. That last part is where jDeploy comes in.

What Is jDeploy?

If you have not heard of jDeploy yet, Steve explains it very well in a few sentences: "Once you finish building a desktop application, you hit a wall. How do you share it? How does your user install it? And when you update it, how do they get the new version without manually downloading and reinstalling?"

jDeploy solves all of that. It creates native installers for Windows (.exe), macOS (.dmg), and Linux, handles auto-update on launch, bundles its own JVM so users do not need Java installed, and uses GitHub Releases as the distribution backend. No Maven Central, no NPM account required. Your GitHub repo is your distribution channel.

I did a full interview with Steve earlier where he explains the background of the tool: JavaFX In Action #12 with Steve Hannah about jDeploy. Worth watching if you want the full picture.

The Video: Preparing and Triggering the First Release Together

This new video is about an hour long and covers the whole process of getting MelodyMatrix ready for V1.0.0. Steve joined me, and we walked through the project configuration together, fixed a few things in the GitHub Actions workflow, discussed best practices around git tags, and then actually triggered the first release build while the camera was still running.

Some of the things we covered:

How jDeploy is configured in the MelodyMatrix project, including how JavaFX preview features are enabled.
npm versus GitHub for the release packages (short version: npm was much easier to get started with than Maven, and Steve modeled the GitHub metadata format on the npm package format).
Why the Windows installer is an .exe file and not a zip (user experience: download, click, done).
How jDeploy manages its own JVM per platform (default is Zulu, with some platform-specific exceptions for Windows ARM and Linux).
Why Maven is not used for application distribution, and why Steve holds his breath every time he does a Maven deploy.
How to set the version number for a release without breaking the path to your jar file.
How to prevent multiple jDeploy workflows from running simultaneously.
Best practices around git tags, including the capital V versus lowercase v debate.
Customizing the installer and launcher splash screen with a custom HTML page.
How jDeploy can use a local build to test the installation before pushing to GitHub.

And around the 57-minute mark, the release build finished on GitHub Actions and MelodyMatrix V1.0.0 was live.

Why jDeploy, and Why It Is Free

jDeploy is completely free! Steve wants Java desktop apps to be easy to deploy, and any barrier to entry works against that goal. He is working on a paid tier with private repositories and deployment authentication, but the core tool stays free.

For a solo developer building a side project like MelodyMatrix, that matters. I can push a new version by tagging a commit, and within minutes there is a new installer available for every platform. Users get it automatically on the next launch. No manual distribution, no "please re-download the installer" emails.

A Side Note on Lottie4J

While waiting for the GitHub Actions build to finish, Steve mentioned he had been experimenting with adding Lottie animation support to the jDeploy splash screen, and we talked about Lottie4J for a bit. That is the kind of thing that happens in a live session. :-) Steve even built a Claude Code skill for creating a custom HTML splash screen with a LottieFiles animation. If you want to try it: jdeploy-claude on GitHub and the custom launcher splash screen skill.

Timeline

00:00 Introduction
00:48 Who is Steve Hannah and why he created jDeploy to distribute Java applications with automatic updates
05:42 How Frank uses jDeploy for MelodyMatrix, demo of the application
07:26 jDeploy configuration in the MelodyMatrix project, how JavaFX preview features are enabled, GitHub Actions
08:32 How new versions get distributed, npm versus Maven versus GitHub
10:56 A look into the GitHub Actions flow for MelodyMatrix
13:38 Why Maven is not used for application distribution
16:38 Why the Windows installer is an .exe file
23:13 The JVM runtimes used by a jDeploy application
26:05 Modifying the splash screen of the installer and application
28:23 The jDeploy desktop app to configure your project
31:46 Preparing the MelodyMatrix project for the first release, how to set the release version number, and improving the GitHub workflow
40:45 Info about the open-source part of the MelodyMatrix project and the struggle between Gradle and Maven
42:59 Checking the GitHub Actions for the release, and more improvements to prevent multiple simultaneous jDeploy workflows
45:39 Best practices regarding the use of git tags
48:42 Starting the build of the first MelodyMatrix release as V1.0.0!
49:40 While the build process is running on GitHub Actions, experimenting with jDeploy locally
54:34 Release builds on GitHub Actions are still busy, so another side step to LottieFiles and Lottie4J, and how they could be integrated in the jDeploy splash screen
57:41 The first release is ready. Installing and trying it...
01:00:40 jDeploy is free! Steve just wants Java to be easy to deploy
01:02:31 Conclusion

Lottie4J 1.2.0: dotLottie Support, Marker Playback, Cropping, and a Big Speed Boost

Frank Delporte — Fri, 20 Mar 2026 10:48:55 +0000

Version 1.2.0 of Lottie4J is out, and it's again a big release! The headline feature is support for the .lottie container format, but that's just the start. This release also brings marker-based playback, cropping, adaptive rendering, significant performance improvements, and a lot of core model fixes driven by testing more complex real-world animations.

dotLottie File Support

Until now, Lottie4J only supported the plain JSON format (.json). That's the original Lottie format, but LottieFiles also introduced a newer container format: .lottie. It's essentially a ZIP archive that can hold one or more animations, embedded images, sounds, and a manifest file that describes the contents.

The .lottie format is a practical improvement: it makes Lottie files smaller and self-contained, bundling images and other assets alongside the animation data instead of relying on external references. Lottie4J now supports loading .lottie files directly via the core FileLoader. There are two loading modes available:

// Load the first animation from a .lottie file (simplest path)
LottieAnimation animation = LottieFileLoader.load(path);

// Load the full .lottie container to access the manifest and all animations
DotLottie lottie = LottieFileLoader.loadDotLottie(path);

The Lottie object gives you access to the manifest (author, version metadata) and the full list of animations. At the moment, most real-world .lottie files I found, only bundle a single animation, but the API is ready for multi-animation files when they appear.

New Player Features

Play Between Markers

Lottie animations can embed named markers. Those are timestamp labels inside the animation JSON that indicate points of interest or looping regions. This is a feature Lottie4J previously parsed but didn't expose in the player. Now it does.

The new play(startMarker, endMarker) method makes the player start at frame 1, and then loop between the two named positions in the timeline.

Cropping Support

LottiePlayer now supports cropping via crop(top, right, bottom, left). This lets you clip the rendered output to a sub-region of the animation canvas, which is handy when you want to embed only part of an animation into a layout without modifying the original file.

Resizable Player

LottiePlayer is now properly resizable and adjusts its rendering accordingly. Resizing also has a secondary effect: smaller sizes reduce the rendering load, so you can trade size for performance when needed.

Performance Improvements

Rendering speed has improved significantly in this release. The main gains come from reducing the number of rendering passes per frame and adding a caching layer for layer and precomp render metadata, which avoids redundant recalculation on heavy animations.

The difference is measurable: one test animation that previously played back at around 20–30 FPS now runs at ~50 FPS. A heavier animation that struggled at 11 FPS now reaches ~31 FPS at full size, and scales higher as the player is resized smaller.

Adaptive Rendering Mode

A new adaptive rendering toggle setAdaptiveOffscreenScalingEnabled(enabled) trades rendering sharpness for speed. In adaptive mode, JavaFX uses a faster rendering path that can introduce slight blurring on some elements (particularly sharp text or fine detail at certain sizes). In non-adaptive mode, rendering is pixel-precise but slower.

Which mode works better depends on the animation: simpler animations often look fine in adaptive mode and benefit from the speed, while text-heavy or detail-rich animations are better left in the default mode. The toggle is exposed in both the LottiePlayer and the file viewers so you can test your specific animations.

Core Model Improvements

A lot of work went into the core library this release, driven by testing more complex real-world Lottie files:

Merge and modifier shape support: a shape layer feature used in more complex animations.
Blend mode support: layers can now carry blend mode instructions that affect compositing.
Spatial bezier interpolation: position animations now correctly interpolate using bezier curves rather than linear paths, which produces the characteristic easing motion that makes Lottie animations feel polished.
Missing model fields: mask, layer, and animation objects had gaps that caused incorrect rendering on specific files, these are now filled in.
Improved JSON output: when recreating a Lottie JSON from the model (write path), value ordering is now more consistent, and the reconstructed file more closely matches the original.

Jackson 3 Upgrade

The core library has been upgraded to Jackson 3. This is a major version bump: the group ID changes from com.fasterxml.jackson to tools.jackson, so if you depend on the core directly and also pull in Jackson yourself, you'll want to align on version 3. The upgrade also includes CVE-related dependency updates and follow-up compatibility fixes that came out of the migration.

Note that jackson-annotations has not yet moved to the tools.jackson group ID and remains on its previous coordinates for now.

Debug Tooling Updates

The LottieFileDebugViewer has been refactored to extract the duplicated WebView JavaScript bridge code into reusable components. The FX versus JS side-by-side views are improved, and the comparison test has better frame synchronization. A new validation mode tests the player at a resized dimension to verify that rendering holds up under scaling.

The automated CompareFxViewWithWebViewTest, which renders both the JavaFX and JavaScript players frame by frame and checks visual similarity, now also uses .lottie files.

Trying It Out

Update your Maven dependency:

<!-- Just the core model, no player -->
<dependency>
    <groupId>com.lottie4j</groupId>
    <artifactId>core</artifactId>
    <version>1.2.0</version>
</dependency>

<!-- JavaFX player -->
<dependency>
    <groupId>com.lottie4j</groupId>
    <artifactId>fxplayer</artifactId>
    <version>1.2.0</version>
</dependency>

The full list of changes is available on GitHub.

What's Next

The automated comparison test still can't run on GitHub Actions because it requires a display. JavaFX 26 (released alongside Java 26 this week) includes headless rendering support, which may make it possible to run the visual regression tests on GitHub Actions. That's the next thing to investigate...

As always: if you run into a Lottie file that doesn't render correctly, please open an issue and attach screenshots. The more real-world files get tested, the better the library gets.

Lottie4J 1.1.0: Better Rendering, Smarter Debugging, and an animated Lottie4J Logo!

Frank Delporte — Tue, 10 Mar 2026 13:24:06 +0000

Just one week after the first public release of Lottie4J, the open-source Java library for rendering Lottie animations in JavaFX, version 1.1.0 is already out. And it's a big one!

A lot happened in that one week. A logo was designed for the project, a Lottie animation was created for that logo (naturally!), and, most importantly, a significant number of rendering improvements landed after testing a much wider range of animation files. That's the reason for the version bump from 1.0.x to 1.1.0: there are some API changes that come with it.

What Is Lottie4J?

LottieFiles is a JSON-based animation format, originally developed at Airbnb, widely used to play back animations on websites and mobile apps. Players exist for JavaScript, Android, iOS, and more, but a Java/JavaFX player was missing. That's the gap I want to fix with Lottie4J.

The library is split into two Maven artifacts:

Core: reads and writes Lottie JSON files, useful if you want to process animations without a player.
FXPlayer: the JavaFX-based animation player.

You can find them on Maven Central.

What's New in Lottie4J v1.1.0

License and API Improvements

The project has switched from GPLv2 to Apache License V2, which makes it much more adoption-friendly for commercial and open-source projects alike. Logging has been migrated to SLF4J, and there have been significant JavaDoc improvements and code restructuring.

Many Rendering Fixes in the JavaFX Player

This release is primarily driven by testing more complex real-world Lottie files and fixing what didn't render correctly. Here's what changed in the FXPlayer module:

Correct path closing (fixing gaps in thick borders)
Better border rendering
Track Matte support — a key compositing feature in Lottie
Fix for a layer disappearance at exact keyframe boundaries
Correct gradient alpha channel parsing for proper transparency
Image layer rendering — images embedded in Lottie files now display correctly
Fix for GradientStroke deserialization and color format handling
Solid color layer rendering
Text rendering — text objects in animations now display in the JavaFX player
Improved animation handling overall
Gaussian Blur effect support added
Fixed layer opacity
Combined multiple trim paths correctly
Fixed animations that start later in the timeline
Fixed stroke style for dotted lines
Fixed fade transitions for overlapping shapes
Improved gradient fills

That's a long list. Animations that were partially broken or visually wrong in 1.0.0 (missing dots, wrong gradients, invisible layers, no text) now render much closer to what the official JavaScript player produces. There are still known open issues: Gaussian blur combined with clipping is tricky in JavaFX, and some complex gradient shapes still differ from the reference player. But the gap has narrowed considerably.

Smarter Debug Tooling

One of the most useful additions in this release is the extended LottieFileDebugViewer. This tool shows the JavaFX player output side by side with the official JavaScript web player, making it immediately obvious where rendering differs.

New in this version:

Screenshot buttons to capture a single frame or all frames at once
A tile viewer that visualizes each layer individually
The ability to export a single layer as a new Lottie file, so you can isolate and test a specific rendering issue without loading the entire animation

There's also a brand-new LottieFileSimpleViewer, a no-frills viewer that just loads a Lottie file and plays it back in a loop using the JavaFX player. Good for quick checks and an example of how you can use the player in your own projects.

Automated Comparison Testing

Perhaps the most exciting developer tooling addition: a unit test called CompareFxViewWithWebViewTest that automates the comparison between the JavaFX player and the JavaScript web player. The test iterates through a list of Lottie files, captures a screenshot every five frames from both players, and compares them for visual similarity. Any frame that differs too much is saved to disk so you can inspect exactly where and how the rendering diverges.

This makes it much easier to track down rendering regressions and verify improvements. Note that the test requires a display (it can't run headless yet — see this open issue), so it won't run on CI for now, but it's extremely useful locally.

Trying It Out

Add the Maven dependency for whichever module you need:

<!-- Just the core model, no player -->
<dependency>
    <groupId>com.lottie4j</groupId>
    <artifactId>lottie4j-core</artifactId>
    <version>1.1.0</version>
</dependency>

<!-- JavaFX player -->
<dependency>
    <groupId>com.lottie4j</groupId>
    <artifactId>lottie4j-fx-player</artifactId>
    <version>1.1.0</version>
</dependency>

The full list of changes between 1.0.0 and 1.1.0 is available on GitHub.

What's Next

The goal isn't to ship a new release every week, but when rendering problems are found in specific animations, the debug tools and automated tests make it much easier to isolate, fix, and verify. If you run into a Lottie file that doesn't render correctly in JavaFX, it can be added to the test suite and investigated.

The biggest open challenge right now is Gaussian blur combined with clipping, which JavaFX makes particularly difficult. That's a known limitation for now.

If you're using Lottie4J in a project, I'd love to hear about it! Share what you've built, report rendering differences you find, and follow along for further progress. Contributions and feedback are very welcome.

Introducing Lottie4J, a Java(FX) Library to Parse and Play Lottie Animation Files

Frank Delporte — Tue, 03 Mar 2026 19:29:54 +0000

I'm proud to present a new JavaFX library: Lottie4J, that brings Lottie animations to JavaFX applications. I first learned about Lottie many years ago when we were developing a mobile app. We used Lottie animations to explain to users how to operate a physical device. The animations made the instructions so much clearer than static images or text alone.

At the time, I wanted to create a similar experience in JavaFX, but I couldn't find a JavaFX player for the Lottie format. So I decided to build one myself. What I didn't realize then was just how complex this journey would be...

What is Lottie?

Lottie is a JSON-based animation file format created by Airbnb that lets designers export animations from various tools and use them on any platform (mobile, web, desktop) as easily as using static images. It's become the industry standard for vector animations because the files are small, scalable, and can be manipulated programmatically.

On the Lottie website, you'll find instructions to use After Effects to create animations, but I hope you know there are way better, less expensive alternatives to Adobe applications... I stepped away from Adobe many years ago and advise you to do the same. Check DaVinci Resolve for video editing and Affinity for drawing applications.

The Complexity of Lottie

You see, the Lottie format, although JSON-based, is incredibly complex and hard to understand. The JSON uses cryptic abbreviated property names like nm for name, fr for frames per second, ddd for "has 3D layers".

The specification uses nested structures for layers, shapes, effects, and animations. Understanding what each property does and how they interact requires diving deep into the documentation and lots of trial and error experiments.

Lottie4J Project

I created Lottie4J as a multi-module Maven project. I started working on this already in 2022, but only now, thanks to the evolutions happening with Claude.ai, I could dive into the Lottie format deep enough to understand it and handle the data correctly to get it visualized and animated in the correct way. Turns out my data model parsing was already correct. Also my first JavaFX rendering worked well, but with some changes in how the nested data structures are handled, I'm now convinced the library is ready to be released as version 1.0.0.'

Project Structure

Lottie4J is organized into three main modules:

Core: The Java objects representing the Lottie data model and file loading
FXPlayer: A JavaFX component that actually plays the animations
FXFileViewer: A demo application that shows animations and visualizes their structure

Making Sense of the JSON

One of my goals was to make the cryptic Lottie format more understandable. In the Animation class in the core library, each cryptic JSON property is mapped to a clear, descriptive name. @JsonProperty("fr") becomes framesPerSecond, @JsonProperty("ip") becomes inPoint. Java objects use human-readable names, making the code self-documenting and much easier to work with.

But I went even further. The fxfileviewer application includes a tree visualizer that lets you explore the structure of any Lottie file in an easy view. You can see exactly what's inside your animation - the layers, shapes, properties, and how they're nested. This was invaluable for understanding the format and debugging animations.

Example Animations

I've included several test animations in the project to showcase the capabilities:

java_duke_flip.json - The Java Duke mascot doing a flip animation
loading.json - A loading spinner animation
sandy_loading.json - A particularly tricky one testing complex nested transformations
timeline_animation.json - A timeline animation showing how multiple elements can be choreographed together

While an animation plays, you can see the complete structure in the tree view - every layer, every shape, every animated property.

How to Use Lottie4J

Using Lottie4J in your JavaFX application is straightforward. Import the fxplayer-dependency in your pom.xml:

<dependency>
    <groupId>com.lottie4j</groupId>
    <artifactId>fxplayer</artifactId>
    <version>1.0.0</version>
</dependency>

Then add the animation with this minimal code example:

LottiePlayer player = new LottiePlayer("path/to/animation.json");
parent.getChildren().add(player);

Load your Lottie JSON file, create a LottiePlayer component, add it to your scene or parent component. That's it! The player handles all the complexity of parsing the animation and rendering it frame by frame.

Continuous Evolution

The Lottie format is constantly evolving with new features and capabilities. There's always more to implement, more edge cases to handle, more animations to test. But that's what makes this project interesting - it's a continuous learning experience.

Get Started

If you're working with JavaFX and want to add beautiful, lightweight animations to your applications, check out Lottie4J. All the code is open source and available on GitHub. You'll find more documentation and examples on lottie4j.com.

Please let me know how you use the library and share your results. I'm sure not all animations will already render completely the same as with the more mature players, so if you find differences, it would be very nice if you could isolate the problem and share the json file with a clear description of the issue in a ticket in the GitHub repository.

Happy animating!

I Benchmarked Java on Single-Board Computers: Orange Pi 5 Ultra and Raspberry Pi 5 Lead the Pack

Frank Delporte — Tue, 24 Feb 2026 09:49:32 +0000

In my "Java on Single Board Computers" series, I already published several posts and videos in which I unpack the board, connect it for the first time, and try to install and run some simple Java code. In this post, I want to share some benchmarks of Java on these boards to get a better idea of the performance we can expect from Java on these platforms.

Already published in this series:

Benchmark Tool

To make the benchmark testing as easy as possible, I created a simple tool (written in Java of course!) that can be executed with JBang. The complete project is available on GitHub at github.com/FDelporte/sbc-java-comparison.

The project consists of two main parts: a runner and a summarizer.

BenchmarkRunner.java - The User Tool

This is the tool you run on your single-board computer. It's a JBang script that:

Detects system information: This uses the OSHI library to gather details about the board, CPU, memory, JVM, and operating system.
Downloads the Renaissance benchmark suite: Automatically fetches the Renaissance Suite if it's not already cached.
Runs the benchmarks: Executes each benchmark three times and calculates the average score.
Saves results locally: Creates a JSON file with all the benchmark data.
Uploads to GitHub: Optionally, the results file can be pushed to the repository via the GitHub API for inclusion in the comparison.

You can run it directly from GitHub with a single command, after setting up your GitHub API token and the repository details (if needed):

export GITHUB_TOKEN={ghp_yourtoken}
export BENCH_GITHUB_OWNER={your_github_account}
export BENCH_GITHUB_REPO={your_fork}
export BENCH_GITHUB_BRANCH={your_branch}

jbang https://github.com/FDelporte/sbc-java-comparison/raw/main/BenchmarkRunner.java

If you want to run it without uploading results, add the --skip-push flag. And if your board has memory constraints, you can limit the heap size with --heap-limit 768m for example.

The script generates a report that looks like this:

{
  "systemInfo" : {
    "boardInfo" : {
      "model" : "RK3588 OPi 5 Ultra",
      ...
    },
    "cpuInfo" : {
      "model" : "RK3588 OPi 5 Ultra",
      "identifier" : "ARM Family 8 Model 0xd0b Stepping r2p0",
      "logicalCores" : 8,
      ...
    },
    "memoryInfo" : {
      "totalMB" : 15964,
      ...
    },
    "jvmInfo" : {
      "version" : "25.0.1",
      ...
    },
    "osInfo" : {
      "family" : "Ubuntu",
      ...
    }
  },
  "results" : [ 
      {
        "name" : "akka-uct",
        "score" : 17702.0,
        "unit" : "ms",
        "description" : "Actor-based concurrency. Interesting for comparing how well thread scheduling works across ARM, x86, and RISC-V kernels."
      },
    ...
  ],
  "timestamp" : "2026-02-18T10:47:46.198052372Z"
}

SummarizeReports.java - The Automation Tool

This tool runs automatically via a GitHub Action whenever a new benchmark result gets added to the repository. This tool:

Loads all files from the report directory.
Finds the unique platforms by CPU model and keeps only the most recent result for each unique CPU.
Generates summary.json, a consolidated file in the data directory.

This summary file is then used by the web dashboard to visualize all the results.

About The Renaissance Benchmark Suite

Rather than creating benchmarks from scratch, I chose to use the Renaissance Benchmark Suite, an open-source project designed specifically for JVM performance evaluation. Renaissance is maintained by researchers and includes a variety of real-world workloads that stress different aspects of the JVM and hardware.

The suite includes benchmarks for parallel computing, functional programming, machine learning, and more. I selected seven benchmarks that are related to the restrictions of single-board computers. I also found out that the scrabble benchmark can't run with Java 25, so it's not included.

akka-uct: Actor-based concurrency, tests thread scheduling across different architectures.
fj-kmeans: Fork/join parallelism with K-Means clustering, stresses CPU and multi-core utilization.
scala-kmeans: Single-threaded K-Means in Scala, provides a single-core performance baseline.
future-genetic: Genetic algorithm using futures, exercises the thread pool and garbage collector.
mnemonics: Serial JDK Streams, baseline for stream processing.
par-mnemonics: Parallel JDK Streams, reveals how well different architectures handle parallelism.
db-shootout: In-memory databases, tests memory bandwidth and subsystem performance.

I specifically avoided the Apache Spark benchmarks from Renaissance, as they're very memory-hungry and designed for multicore server machines. They would either crash with OutOfMemoryErrors or take forever on these constrained boards.

The Results

Based on the automatically generated summary.json and other configuration files in the repository's data directory, I created (with a lot of help of Claude.ai...) an interactive dashboard to visualize all the results. You can explore it yourself at webtechie.be/sbc/.

Important note: I ran the tests on the default Ubuntu system provided by the manufacturer of the board, after doing an update/upgrade and installation of OpenJDK 25 and JBang. The runner itself also uses some resources of the board, so this influences the numbers, but the same approach has been used on all boards to have a similar comparison.

The Dashboard

The "Vanilla JavaScript" (= no libraries, just HTML/CSS/JS) dashboard presents the benchmark results in an easy-to-understand format. For each board, you can see:

System information: Board model, CPU details, memory, Java version, and operating system.
Individual benchmark scores for each of the seven tests.
Visual comparisons across all tested boards.

The dashboard pulls the latest summary and other data files from the repository, so it's a living comparison that grows as more test reports become available.

These are screenshots from a first test round. Check the actual last status at webtechie.be/sbc/.

Analyzing the Results

Some general remarks about the charts:

The overview chart at the top gives the best board (based on your selection) a score of 100% (best), and the other boards are compared to it.
For the other charts, per benchmark, the lower scores are better. All benchmarks measure execution time in milliseconds, so lower numbers indicate faster performance.
Because of the limited amount of memory on the BeagleV-Fire, the benchmarks were executed with --heap-limit 768m on this board to avoid JVM crashes. This is also a factor leading to the lower scores for this board.

Performance Leaders

Not surprisingly, my Apple M2 workstation dominates the charts with the fastest scores across all benchmarks. This is expected, it's a high-end desktop processor with 12 cores and significantly more power budget than any single-board computer. The LattePanda IOTA with its Intel N150 x86 processor also performs exceptionally well, coming in second place on most tests.

The LattePanda IOTA deserves special attention here. While I initially excluded it from the "true" single-board computer competition, the pricing actually deserves reconsideration. At 110€, it's comparable to a Raspberry Pi 5 with additional M.2 expansion. The IOTA comes pre-equipped with an M.2 slot for NVMe storage expansion, full-size HDMI, three USB ports, and GPIO headers, all integrated into one board. However, it does require active cooling (the "do not operate without a heatsink" warning is serious), has a slightly larger form factor than traditional Raspberry Pi boards, and demands more power. It's still more of a compact x86 PC than a Raspberry Pi competitor, but for users who specifically need x86 compatibility (running existing x86 applications, Windows support if needed, or specific libraries), it offers exceptional performance for the price.

For traditional single-board computer use cases like IoT, robotics, GPIO-heavy projects, etc. the ARM-based boards remain the better choice. Definitely the GPIO headers have an advantage on the Raspberry Pi, Orange Pi, and similar boards. I tried the GPIOs on the LattePanda IOTA, and found out that they are exposed by a RP2040 co-processor which connects to the Intel CPU via USB. A strange approach which will be hard to use with the Pi4J library.

The Real Single-Board Computer Competition

Among the boards that fit the traditional SBC form factor (Raspberry Pi-sized, passive or small fan cooling, under $200), the results tell a more nuanced story:

Orange Pi 5 Ultra (ARM RK3588, 8 cores) shows the best results in most of the tests, particularly on multithreaded workloads.
Raspberry Pi 5 (ARM Cortex-A76, 4 cores @ 2.4GHz) delivers solid, consistent performance across all benchmarks, very close to the Orange Pi 5 Ultra.
Raspberry Pi 4 (ARM Cortex-A72, 4 cores @ 1.8GHz) still performs admirably despite being an older generation.
All others show significantly lower performance, which is expected given their lower core counts and less powerful CPUs.

RISC-V Performance

The RISC-V boards present an interesting case. The Orange Pi RV2, BeagleV-Fire, and StarFive VisionFive 2 Lite show that RISC-V is absolutely viable for running Java applications, though performance still lags behind ARM equivalents. This is expected given that RISC-V is a newer architecture with less mature tooling and optimization.

Selecting a Winner

If I had to pick a winner from the "true" single-board computers (excluding my Apple workstation and the LattePanda IOTA), the OrangePi 5 Ultra comes out on top, but the Raspberry Pi 5 is a very close second. These boards offer the best combination of performance and price. Raspberry Pi has the added advantage of a big ecosystem support, and ease of use with the Imager Tool. Orange Pi can still learn a lot from the extensive documentation, and huge library of compatible accessories and software that is available for Raspberry Pi.

Conclusion

I wanted to run benchmarks on multiple boards but needed a solution to do this as quickly and easily as possible. After all, this is a pet project for me. I got the boards for free, but comparing them is a personal challenge in my "free" time... With the current setup with the two scripts, I found a solution which is fast to execute. I only need access from my work PC, copy the GitHub token and JBang command, and let the test run in the background. The GitHub Action then automatically pushes the results to the repository and updates the dashboard. So, goal achieved! :-)

The results confirm: Java runs without problems on all these platforms, from ARM to x86 to RISC-V! Of course, there are performance differences between architectures and specific boards, but every single one of the tested devices can run real-world Java applications with a good performance.

Try It Yourself!

I encourage you to run the benchmark on your own boards and contribute the results! The process is simple:

# Make sure you have Java 25 and JBang installed
jbang https://github.com/FDelporte/sbc-java-comparison/raw/main/BenchmarkRunner.java  --skip-push

If you want your results added to the public dashboard, follow the instructions in the repository README to set up GitHub API access and submit your results.

What's Next?

This is just the beginning! I also received two Banana Pi boards I still need to unpack and test. And it would also be great to add a benchmark for JavaFX performance, but that will exclude RISC-V as there is no JavaFX port for it (yet?). And, of course, I really want to get started with exploring Pi4J on all these boards and see how it compares to the GPIO use of the Raspberry Pi.

If you have suggestions for additional benchmarks or want to see specific boards tested, let me know in the comments or reach out on Mastodon, Bluesky, or my YouTube community!

JavaFX In Action #26 with Helal Anwar about GradedAttendance to Organize Class Rooms, Students, Teachers, and Lessons

Frank Delporte — Thu, 19 Feb 2026 08:13:40 +0000

Every week, I collect a list of posts, social messages, videos, etc. related to JavaFX on the JFX Central Links Of The Week. One of the regular "appearances" is Helal Anwar, who is building impressive educational tools with JavaFX. In this interview, we discuss his GradedAttendance application and other JavaFX projects he's working on.

About Helal

Helal Anwar is an undergraduate student, passionate about creating practical solutions for educational environments. His philosophy on programming is clear: "Programming isn't about what you know; it's about what you can figure out." With experience in both teaching and software development, he has identified common classroom management challenges and developed JavaFX-based tools to address them.

He is an active contributor to the JavaFX community, regularly sharing his projects and insights on social media, making him a frequent feature in the JavaFX Links of the Week on JFX Central. Beyond GradedAttendance, he has created several other JavaFX applications, including a Quiz App, Calculator, Media Player, and Sliding Puzzle game.

You can find him and his work on:

About GradedAttendance

GradedAttendance is a desktop application built with JavaFX to manage student attendance and classroom activities in educational settings. The application demonstrates several key advantages of using JavaFX for educational tools, making it a perfect solution for teachers and educational institutions.

Why JavaFX for Educational Tools

The choice of JavaFX as the development platform was deliberate and well-justified. Unlike web-based solutions, a desktop application built with JavaFX offers several critical advantages:

Offline functionality: The app works without an internet connection, which is crucial in educational environments where connectivity might be unreliable.
Data privacy: All data is processed and stored locally, ensuring student information remains secure and cannot be uploaded to external services.
Performance: Desktop applications provide better performance and responsiveness compared to web-based alternatives.
Stability: Java and JavaFX are mature, stable platforms with extensive documentation and examples that remain relevant over time.

Technical Implementation and Design

The application showcases several JavaFX features and best practices. Helal is a big fan of Scene Builder for designing user interfaces, which allows for visual layout design and rapid prototyping. The application takes full advantage of JavaFX's rendering capabilities to create a polished, professional interface that renders beautifully within the JavaFX framework.

For data storage, GradedAttendance uses SQLite. Despite its name suggesting "light," SQLite provides a full-featured database that's perfect for desktop applications, handling all data storage needs efficiently while keeping everything local to the user's machine.

The Open Source Philosophy

The project is open source, shared with the community not necessarily to gather contributors (though they're welcome), but primarily to help others who might face similar challenges. Helal's philosophy is simple: when he couldn't find a solution to his problem, he created one and shared it so others wouldn't have to start from scratch.

Learning JavaFX with Modern Tools

An interesting point raised during the interview is the value of JavaFX's maturity when it comes to learning and problem-solving. Tools like ChatGPT and other AI assistants have been trained on extensive JavaFX documentation and examples accumulated over years. This means that even older examples and tutorials remain relevant and useful for learning JavaFX, making it easier for newcomers to get started. The stability of the platform ensures that knowledge gained years ago is still applicable today.

The State of JavaFX in Education

The interview touched an important issue: many educational institutions still teach older Java GUI frameworks like Swing, despite JavaFX being a more modern and capable alternative. As Helal pointed out, when he was taught Java in college, they were still teaching Swing. His question was simple but important: "Why are you teaching Swing? There's a better thing available. Why not teach that?" This highlights the need for greater awareness of JavaFX's capabilities in academic settings.

Looking at the Code

When discussing what he's most proud of in the codebase, Helal mentioned the integration of various libraries that make the application powerful yet maintainable. The use of AtlantaFX for theming, CalendarFX for scheduling features, and Ikonli for icons creates a modern, professional application. The application also incorporates JLatexMath for rendering mathematical formulas, which is particularly useful in educational contexts, and SQLite JDBC for robust database connectivity.

You can find more information about GradedAttendance on:

GitHub repository

Used libraries and other links from the video:

AtlantaFX: Modern JavaFX theme
CalendarFX: Calendar and scheduling components
Ikonli: Icon packs for Java applications
JLatexMath: LaTeX rendering for Java
SQLite JDBC: JDBC driver for SQLite
egui: Immediate mode GUI in Rust library
Xilem: Experimental Rust native UI framework
MelodyMatrix: JavaFX application to visualize music

Video content

00:00 Who is Helal

00:57 How GradedAttendance started (thanks to SceneBuilder)

02:29 About GradedAttendance and demo of the application

06:47 Why JavaFX and not a browser application?

07:40 Challenges during development (database)

10:05 Goal of making it as an open-source project

11:25 Other projects Helal worked on

13:04 Learning from books and chat systems

13:45 How GradedAttendance became bigger thanks to MelodyMatrix and AtlantaFX

14:59 Helal wants to see JavaFX more used in programming classes

15:45 Thanks to the many Java library creators!

More JFX In Action...

Click here for more posts with JFX In Action videos.

I Got Java 25 Running on the RISC-V BeagleBoard BeagleV-Fire

Frank Delporte — Fri, 13 Feb 2026 13:02:35 +0000

After my initial struggles with the BeagleV-Fire in a previous video, I succeeded in getting Java 25 running on RISC-V-powered BeagleV-Fire! Let me walk you through the journey and the steps I took to make it work.

The Challenge

In my earlier blog post and video about several BeagleBoards, I demonstrated that Java, JavaFX, and even Pi4J worked perfectly. That's expected, since ARM processors, like those in Raspberry Pi boards, have run Java reliably for years.

However, the BeagleV-Fire with its RISC-V processor presented a different story. The board came pre-installed with Ubuntu 23, and I hit a wall immediately. The apt repositories were outdated and no longer available, making it impossible to install Java or update the system to a newer Ubuntu version.

The Solution: BeagleBoard Imaging Utility

The key to solving this problem was updating the operating system using the BeagleBoard Imaging Utility. Unlike Raspberry Pi boards that use SD cards, the BeagleV-Fire has eMMC storage with the operating system pre-installed. This means you need to replace the board's existing OS with a newer version. The process took about half an hour in real time (though I've edited the video down significantly), including updating the system and installing all the latest dependencies.

Serial Connection Setup

As described on the BeagleBoard Documentation > Boards > BeagleV-Fire > Quick Start, you need a serial connection to see what the board is doing and interrupt it at the right moment to make it accessible from the Imaging Utility. I used a DSD TECH USB to TTL Serial Cable.

You also need a USB-to-USB cable to connect the board to your computer.

Failed With macOS

I initially tried connecting the board to my Apple workstation via USB. Despite the USB-to-serial cable being detected, I ran into issues:

% ls -l /dev/tty.*
crw-rw-rw-  1 root  wheel  0x9000002 Jan 19 09:15 /dev/tty.Bluetooth-Incoming-Port
crw-rw-rw-  1 root  wheel  0x9000000 Jan 19 09:13 /dev/tty.debug-console
crw-rw-rw-  1 root  wheel  0x9000004 Feb 10 16:19 /dev/tty.usbserial-BG02SIJE

% screen /dev/tty.usbserial-BG02SIJE 115200

The board itself never appeared as a USB drive, so the BeagleBoard Imaging Utility didn't detect it, and while I could start a screen session, no output from the BeagleBoard appeared. This could be a macOS-specific issue, related to security not allowing such USB devices, so I switched strategies.

Succeeded With Linux

On a Linux machine, everything worked as expected! The USB-to-serial cable was properly detected, something you can easily verify with the dmesg command:

$ dmesg
[4:58 PM][2353475.078097] usb 1-5: new full-speed USB device number 7 using xhci_hcd
[2353475.210940] usb 1-5: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[2353475.210946] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2353475.210948] usb 1-5: Product: FT232R USB UART
[2353475.210950] usb 1-5: Manufacturer: FTDI
[2353475.210951] usb 1-5: SerialNumber: BG02SIJE
[2353475.266287] usbcore: registered new interface driver usbserial_generic
[2353475.266305] usbserial: USB Serial support registered for generic
[2353475.269477] usbcore: registered new interface driver ftdi_sio
[2353475.269497] usbserial: USB Serial support registered for FTDI USB Serial Device
[2353475.269533] ftdi_sio 1-5:1.0: FTDI USB Serial Device converter detected
[2353475.269571] usb 1-5: Detected FT232R
[2353475.270001] usb 1-5: FTDI USB Serial Device converter now attached to ttyUSB0

$ sudo apt install screen
$ sudo screen /dev/ttyUSB0 115200

With the serial connection established, check the board output in the screen session and wait for the message Press a key to enter CLI to appear. You have one second to react, so be fast! :-)

Then type in the following two commands:

>> mmc
>> usbdmsc

Now the board should appear as a USB drive on your computer and as a device in the Imaging Utility for an OS update. I had to do this twice because Wi-Fi was enabled, which caused an error at the end of the first attempt. After disabling the Wi-Fi settings, the update succeeded, and the board rebooted to Ubuntu 24!

Installing Java 25

Once Ubuntu 24 was up and running on the BeagleV-Fire, installing Java 25 was straightforward using the standard apt install command. Java 25 is the latest Long-Term Support (LTS) version, meaning it will be maintained for a long time. While Java 26 will be released in March, that's a short-term version with only six months of support. I'm happy to start with Java 25 on this board, though Java 26 should work just as well once it becomes available through apt.

I also installed SDKMAN and JBang to test a few of the Pi4J JBang examples.

sudo apt update
sudo apt upgrade
sudo apt install zip
curl -s "https://get.sdkman.io" | bash

# Close the terminal and open a new one
sdk install jbang

# Install OpenJDK 25
sudo apt install openjdk-25-jdk

# Get the Pi4J JBang repository
git clone https://github.com/Pi4J/pi4j-jbang.git
cd pi4j-jbang
cd basic
java HelloWorld.java
jbang HelloJavaFXWorld.java

What's Next: Performance Testing

Now that I have Java 25 running on both ARM and RISC-V boards, the big question remains: how do they compare in terms of performance? That's exactly what I plan to explore throughout 2026. My goal is to create a reusable Java performance test that I can run across all these single-board computers to compare:

ARM processors (like the BeagleY-AI and Raspberry Pi)
RISC-V processors (like the BeagleV-Fire and BeagleV Ahead)
Eventually, x86 processors on single-board computers as well

This will help us understand what's achievable with these affordable single-board computers and which architecture performs best for Java development, and which board is the best choice for a specific use case.

Conclusion

Getting Java running on RISC-V is a reality! While the process required a few extra steps compared to ARM boards, the BeagleV-Fire is now running Ubuntu 24 with Java 25 and is ready for experimentation.

If you're interested in following along with my "2026 single-board computer testing plan", or if you have specific tests you'd like me to run, please let me know! Don't forget to subscribe to my YouTube channel for future updates.

First Test of Java on BeagleBoards (ARM and RISC-V)

Frank Delporte — Tue, 10 Feb 2026 19:31:50 +0000

As part of my 2026 learning goals around Java on RISC-V (see this post about x86 versus ARM versus RISC-V), I've asked various suppliers to send me evaluation boards. I already published these:

LattePanda IOTA (x86)
OrangePi 5 Ultra (ARM) and OrangePi RV2 (RISC-V)
VisionFive 2 Lite (RISC-V)
In this post: BeagleBoards (ARM and RISC-V)

I got all these boards for free, but what I write here and show in the video is not controlled by StarFive or any other supplier.

ARM versus RISC-V?

ARM and RISC-V represent two different approaches to processor design. ARM is the established player we know from, e.g., the Raspberry Pi's. It's mature, and has a huge ecosystem of tools and support built over decades. RISC-V is the open-source alternative, free from licensing restrictions and fully transparent. While ARM still leads in performance and tooling today, RISC-V is catching up fast. The real difference isn't just about speed. It's about openness and flexibility. With RISC-V, you're not locked into a vendor's ecosystem, and you have complete visibility into how your hardware works.

BeagleBoards

BeagleBoard has a wide range of single-board-computers in Raspberry Pi-like and Arduino-like formats. Here's how the BeagleBoards I received, compare to the latest Raspberry Pi's:

Board	SOC	Type	CPU	Cores	Speed	Price
Raspberry Pi 4	BCM2711	ARMv8	Cortex-A72	4	1.8Ghz	68€ (4GB)
Raspberry Pi 5	BCM2712	ARMv8	Cortex-A76	4	2.4Ghz	79€ (4GB)
BeagleY-AI	Texas AM67A	ARM	Cortex-A53	4	1.4Ghz	73$
BeagleV-Fire		RISC-V + FPGA		1+4		149$
BeagleV-Ahead	Alibaba TH1520	RISC-V		4	2GHz	149$
PocketBeagle 2		ARM	Cortex-A53	4	1.4Ghz	29$

Test Boards

I received the following boards.

BeagleY-AI

BeagleY®-AI is a low-cost, open-source, community-supported development platform for developers and hobbyists in a familiar form-factor compatible with accessories available for other popular single board computers. Users benefit from BeagleBoard.org-provided Debian Linux software images with a built-in development environment and the ability to run artificial intelligence applications on a dedicated 4 TOPS co-processor along with real-time I/O tasks on a dedicated 800MHz microcontroller. BeagleY®-AI is designed to meet the needs of professional developers and classroom-environments alike being affordable and easy-to-use, while being open source hardware such that developers barriers are eliminated to how deep the lessons can go or how far you can take the design in practical applications.

BeagleV-Fire

BeagleV®-Fire is a revolutionary single-board computer (SBC) powered by the Microchip’s PolarFire® MPFS025T 5x core RISC-V System on Chip (SoC) with FPGA fabric. BeagleV®-Fire opens up new horizons for developers, tinkerers, and the open-source community to explore the vast potential of RISC-V architecture and FPGA technology. It has the same P8 & P9 cape header pins as BeagleBone Black allowing you to stack your favorite BeagleBone cape on top to expand it’s capability. Built around the powerful and energy-efficient RISC-V instruction set architecture (ISA) along with its versatile FPGA fabric, BeagleV®-Fire SBC offers unparalleled opportunities for developers, hobbyists, and researchers to explore and experiment with RISC-V technology.

BeagleV-Ahead

BeagleV®-Ahead is an open-source RISC-V single board computer (SBC) with BeagleBone Black cape header pins allowing you to stack your favorite BeagleBone cape on top to expand it’s capability. Featuring a powerful quad-core RISC-V processor, BeagleV®-Ahead is designed as an affordable RISC-V enabled pocket-size computer for anybody who want’s to dive deep into the new RISC-V ISA.

PocketBeagle 2

PocketBeagle 2 is an upgraded version of the popular PocketBeagle, designed as an ultra-compact, low-cost, and powerful single-board computer (SBC). Targeted at developers, students, and hobbyists, PocketBeagle 2 retains the simplicity and flexibility of its predecessor while delivering enhanced performance and expanded features to support modern development needs. PocketBeagle 2 is ideal for creating IoT devices, robotics projects, and educational applications. Its small form factor and low power consumption make it a versatile platform for embedded development, whether prototyping or deploying at scale.

Product page
Documentation
PocketBeagle TechLab: Designed from lessons-learned in teaching hundreds of individuals getting their first introduction to programming, Linux, and ultimately hacking the kernel itself.

First Tests

The easiest way to get started with a BeagleBoard and burn the latest OS on an SD card, is the BeagleBoard Imaging Utility, available for Windows, macOS and Linux. This is the first supplier of SBC's that provides such a tool that is comparable to the Raspberry Pi Imager Tool. It's a crucial factor to get started with a new type of SBC, and BeagleBoard has done a great job in making this tool available.

BeagleY-AI (ARM Processor)

This board delivered the smoothest experience of all four BeagleBoards. Using BeagleBoard's excellent Imaging Utility, I created an SD card with the latest OS, providing the username and password I want to use via the settings. With the SD card installed, I connected it via micro HDMI and USB, and booted into a desktop environment within minutes. After the standard update and `upgrade, I installed SDKMAN, Java (Azul Zulu 25.0.2 with JavaFX support), and JBang. The JavaFX test application from tge Pi4J JBang repository ran flawlessly, confirming that both Java and JavaFX work perfectly on this ARM-based board. It's very comparable to the Raspberry Pi 5, even sharing similar connector placement, making it an excellent choice for Java development.

`
sudo apt update
sudo apt upgrade
sudo apt install zip
curl -s "https://get.sdkman.io" | bash

Close the terminal and open a new one

sdk install java 25.0.1-zulu-fx
sdk install jbang

Close the terminal and open a new one

git clone https://github.com/Pi4J/pi4j-jbang.git
cd pi4j-jbang
cd javafx
jbang HelloJavaFXWorld.java
`

BeagleV-Fire (RISC-V Processor)

This board proved challenging due to my Raspberry Pi habits. I initially created an SD card using the Imaging Utility, not realizing the board already has Ubuntu pre-installed in its eMMC storage. Unfortunately, it's running Ubuntu 23.04, which is no longer maintained, preventing me from updating or installing Java through the package manager. The correct approach requires connecting the board via USB to my computer and flashing the eMMC directly using the Imaging Utility's device mode, but I haven't successfully completed this process yet. While Java RISC-V builds exist and should theoretically work, I need to resolve the OS update issue first before confirming Java compatibility.

Default username and password are beagle:temppwd.

% ssh beagle@10.120.10.11 Ubuntu 23.04 BeagleBoard.org Ubuntu 23.04 Console Image 2023-10-19 Support: https://bbb.io/debian default username:password is [beagle:temppwd]

BeagleV-Ahead (RISC-V Processor)

This larger RISC-V board presents its own unique challenges. Unlike modern boards, it requires a traditional 5-volt barrel connector instead of USB-C for power. I successfully connected to it via SSH over my network, but discovered it runs a custom Linux distribution specifically built for its processor, one I didn't recognize and couldn't identify as Debian or Ubuntu-based. The apt package manager doesn't function on this distribution, leaving me unable to install Java through standard methods. While Java RISC-V builds should theoretically be compatible, I need to dive deeper into the documentation to understand this custom distribution and determine the proper installation approach.

Default username is root without a password.

cat /etc/*-release

commit-id:52fbe8443ea11d7e0abf958a8e2a202d67ef40c1
ID=thead-c910
NAME="THEAD C910 Release Distro"
VERSION="1.1.2"
VERSION_ID=1.1.2
PRETTY_NAME="THEAD C910 Release Distro 1.1.2"
BUILD_ID="20230609164851"
HOME_URL="https://occ.t-head.cn/"

apt search openjdk

Sorting... Done
Full Text Search... Done

apt install java

Reading package lists... Done
Building dependency tree... Done
E: Unable to locate package java
`

PocketBeagle 2 2 (ARM Processor)

This tiny ARM-based board uses the Cortex A53 processor (the same as the BeagleY-AI), which means Java should run without issues since ARM Java distributions are readily available. I haven't tested it yet, but I'm confident it will work. The exciting part is the included Tech Lab kit with buttons and RGB LEDs that mount directly on top of the board, making it an ideal platform for coding clubs and educational settings where you want to combine programming with physical computing experiments. This compact form factor paired with interactive hardware makes it a promising board for hands-on Java experimentation.

Conclusion

My congratulations to BeagleBoard for their documentation website and Imaging Utility! That really sets them apart from other single-board computer suppliers I tested before. Java on BeagleY-AI runs within minutes of starting my tests, and I'm confident I'll be able to use it for further experiments.

For the other boards, I'll need some more time to figure out how to proceed. The BeagleV-Fire needs a newer version of Ubuntu, and the Linux version on the BeagleV-Ahead is still a mystery to me...

As I set my goals for 2026 to learn more about different types of single-board-computers that's a perfect conclusion. It's just the beginning of 2026, so I have still more than 10 months this year to achieve my goal ;-)

JavaFX In Action #25 with Lidiany Cerqueira about CERCA, a tool to detect hallucinated references in scientific papers

Frank Delporte — Thu, 05 Feb 2026 15:34:19 +0000

Every week I collect a list of posts, social messages, videos, etc. related to JavaFX on the JFX Central Links Of The Week. That's how I recently found a message from Lidiany Cerqueira on LinkedIn about CERCA. It's a tool she created during her Christmas break to detect false/hallucinated references in scientific manuscripts.

About Lidiany

Lidiany Cerqueira is a Senior Software Engineer and Computer Science researcher, living in Brazil, and working at the intersection of software engineering and human values. With over 15 years of industry experience and a PhD in Computer Science, her research interests include software engineering, human-centered computing, and empirical research.

She has experience in teaching and outreach, working with students from both traditional computer science programs and non-CS backgrounds, and is a strong advocate for diversity and inclusion in technology, and currently serves as a Community Manager at BRAVAS in Tech.

She created the CERCA application because she serves as an active reviewer for top-tier software engineering venues and is a member of the program committee for several conferences, contributing to the research community through peer review and service.

You can find her on:

About CERCA

CERCA is an open-source research tool that supports the verification of bibliographic references in scientific manuscripts. It extracts references from PDF files and checks their existence and consistency against authoritative metadata sources, producing explainable diagnostics, audit logs, and reproducible reports.

You can find more information about CERCA on:

Used libraries and APIs:

Video content

00:00 Who is Lidiany

01:13 The problem of hallucinated references in academic papers

03:23 The goal of CERCA and why it's developed with Java(FX)

05:07 Demo of CERCA

13:30 Reading reference lists from other file formats

15:32 Export report to text

16:34 Database APIs used for checking references

17:47 Papers must be processed locally as they may not be uploaded to any service

19:30 Why Java(FX) was the best solution to build CERCA

21:25 A look into the code and the used libraries

24:49 Call for contributions

25:53 About the (Brazilian) Java and other communities

More JFX In Action...

Click here for more posts with JFX In Action videos.

OpenJDK January 2026 Critical Patch Update and Patch Set Update Released

Frank Delporte — Fri, 23 Jan 2026 09:56:51 +0000

The January 2026 OpenJDK quarterly updates are now (or will soon be) available from various OpenJDK distributors. This quarterly release brings important security fixes and updates to all currently supported Java versions.

The Quarterly Update Cycle

Every three months (in January, April, July, and October), the OpenJDK project releases security updates, bug fixes, and improvements for all supported Java versions. This predictable schedule helps organizations plan their Java updates and maintain secure, stable production environments.

These quarterly releases come in two flavors: Critical Patch Updates and Patch Set Updates.

Critical Patch Updates (CPU)

CPU releases focus exclusively on security. They contain:

Fixes for security vulnerabilities
Critical bug fixes only

CPUs are based on the previous quarter's PSU release with only security patches applied. This conservative approach makes them ideal for deploying urgent security fixes with minimal risk of introducing new issues. If stability is your top priority and you want to avoid any non-security changes, CPU releases are your go-to option.

Patch Set Updates (PSU)

PSU releases provide a more comprehensive update by incorporating:

All security fixes from the corresponding CPU
Additional non-security bug fixes
Alignment with the associated OpenJDK project quarterly release

PSUs offer the full set of improvements and refinements from the OpenJDK community while still maintaining the stability expected from a minor update.

In an ideal scenario, you install a CPU as soon as possible after a brief test to secure your environment. After that, you start testing with the PSU release for a longer time. Once all your tests are green, switch your environment to the PSU version. This must be completed before the next quarterly update, so you can easily repeat the cycle.

Difference With the Six-Month Release Cycle

The six-month release cycle, introduced with OpenJDK 9, brings a new major OpenJDK version in March and September. For example, on September 16, 2026, we saw the "birth" of Java 25 (25.0.0).

Since then, we already had the October CPU/PSU release, which brought the first security and bug fixes to all supported versions, so also bumping Java 25 to 25.0.1.

The quarterly cycle brings updates to existing releases. For example, the January CPU/PSU release bumps the PSU versions (from/to):

25.0.1 -> 25.0.2
21.0.9 -> 21.0.10
17.0.17 -> 17.0.18
11.0.29 -> 11.0.30

Important message: to keep your systems secure, you need to install a JDK update every 3 months. Check java -version to understand how many updates you missed. For instance, if you installed the first release of JDK 17 (17.0.0), you have missed 18 updates with security and bug fixes by now!

Distributor Availability

The beauty of the OpenJDK ecosystem is that multiple distributors provide builds of these releases. Major OpenJDK distributors, including Azul (Zulu), BellSoft, Oracle, Eclipse (Temurin), and others, typically make updated builds available for all currently supported Java versions within a few hours or days. This typically includes:

Current LTS (Long-Term Support) versions (11, 17, 21, 25).
The latest non-LTS release (till six months after its release).
Extended support versions (depending on your distributor, for instance, Azul for Java 6, 7, and 8)

Check with your specific OpenJDK distributor to confirm which versions receive updates and the support timeline for your deployment.

In this January Release

The January release, as stated by Oracle, contains 11 new security patches for Oracle Java SE. All of these vulnerabilities may be remotely exploitable without authentication, i.e., may be exploited over a network without requiring user credentials. The highest CVSS v3.1 Base Score of vulnerabilities affecting Oracle Java SE is 7.5.

Number of total bug fixes and improvements included in today’s OpenJDK update release:

Java 25: 380
Java 21: 384
Java 17: 349
Java 11: 65
Java 8: 64

Azul has also posted its release notes, which you can find here. One of the highlights: new features in Azul's integration of Coordinated Restore at Checkpoint (CRaC):

Image Encryption: By default, the CRaC images contain application data, including environment variables and arguments, in plaintext. If this data contains secrets and the images are accessible to untrusted parties, you can encrypt the images to ensure the secrets stay hidden.
Alternative Images: Automatically select the best CRaC image at restore. This brings a solution to modern cloud environments where a single checkpoint image may not be enough

Next Steps

Review the release notes from your OpenJDK distributor to understand the specific fixes and improvements in this quarter's release. Plan your testing and deployment schedule to ensure your Java applications benefit from the latest security patches and bug fixes.

Mark your calendar, the next quarterly updates and releases arrive on:

2026-03-17: OpenJDK 26 release
2026-04-21: CPU/PSU Update
2026-07-21: CPU/PSU Update
2026-09-15: OpenJDK 27 release
2026-10-20: CPU/PSU Update
2027-01-19: CPU/PSU Update
2027-03-23: OpenJDK 28 release
2027-04-20: CPU/PSU Update
2027-07-20: CPU/PSU Update
2027-09-21: OpenJDK 29 (LTS) release