DEV Community: Frank Delporte

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

[Boost]

Frank Delporte — Fri, 16 Jan 2026 16:01:02 +0000

How I Built a Tool to Detect AI-Generated Fake References

lidianycs ・ Jan 5

#opensource #java #github #programming

First Test of Java on the VisionFive 2 Lite (RISC-V)

Frank Delporte — Fri, 16 Jan 2026 15:56:59 +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 asking various suppliers to send me evaluation boards. I already published about two and adding a third one now:

LattePanda IOTA
OrangePi 5 Ultra and OrangePi RV2
In this post: StarFive VisionFive 2 Lite

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

Why RISC-V?

RISC-V is an open standard instruction set architecture, driving by the community. Unlike architectures from ARM, Intel, and AMD which must be licensed. This openness has lead to innovation across the industry, and boards like the VisionFive 2 Lite make it accessible to developers like us who want to experiment with (Java) applications on alternative architectures.

StarFive VisionFive

The VisionFive from StarFive is a range of affordable boards for your first steps into the RISC-V world. Here's how the VisionFive's 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)
VisionFive	U74	RISC-V		2	1.25GHz
VisionFive 2	JH7110	RISC-V		4	1.5GHz	87€ (4GB)
VisionFive 2 Lite	JH7110S	RISC-V		4	1.25GHz	59€ (4GB)

Test Board

I received a VisionFive 2 Lite for testing:

Product page
Documentation
Quick Start Guide
Ubuntu Images and other software
- Used: ubuntu-24.04.3-preinstalled-desktop-riscv64+vf2-lite.img

I burned the Ubuntu image to an SD card, but if you want to use eMMC, you can follow these instructions: Flashing OS to Onboard eMMC (eMMC Version). This OS has the pre-configured account user with password starfive.

On the Ubuntu website, more installation instructions are available for a lot of different boards, e.g. for the VisionFive 2 Lite.

Getting Started

Hardware Setup

The board arrived well-packaged, and has a very similar layout to the Raspberry Pi 5. Biggest connection difference: one big HDMI connector instead of two micro-HDMI ports.

Installing Ubuntu

StarFive provides several OS options, but I opted for Ubuntu 24.04.3 LTS Desktop for RISC-V. The process is well-documented:

Download the image: ubuntu-24.04.3-preinstalled-desktop-riscv64+vf2-lite.img from the StarFive GitHub releases
Burn the image to an SD card (I used the Raspberry Pi Imager tool)
First boot uses user as the username with password starfive

The first boot took a bit longer than expected before the desktop appeared. Once up, the system felt responsive for basic tasks, though noticeably slower than a Raspberry Pi 5.

Java Installation and Testing

This is where things get interesting. RISC-V support in the Java ecosystem has improved significantly, but it's still relatively new compared to ARM and x86_64.

Installing Java

Ubuntu for RISC-V includes OpenJDK in the repositories, so it can be installed with sudo apt install, after you have done update and upgrade:

sudo apt update
sudo apt upgrade
sudo apt install openjdk-25-jdk

This installed OpenJDK 25.0.1, built for RISC-V architecture. The installation was straightforward, taking only a few minutes including dependencies. To verify the installation:

java -version

Simple Java Tests

I just wanted to quickly try out a few existing test scripts, and used my JBang project in the Pi4J repositories. As you can see in the video "plain" Java and libraries work as expected. Pi4J and JavaFX were not successful, but also that was expected. I will try Pi4J after the release of its version 4, when it uses the Foreign Function and Memory (FFM) API. As we installed a "normal OpenJDK Build", which doesn't include the JavaFX dependencies, we can't run the example.

Conclusion

The VisionFive 2 Lite is an intriguing board for Java developers curious about RISC-V. At around 60€, it's an accessible way to explore this "other type of" architecture without significant investment. The performance isn't going to compete with a recent Raspberry Pi, but that's not really the point. My first goal was to find out if Java works on it (of course!), and how easy it us to use. And of course, to feed my curiosity to learn new stuff...

Later more, when I try to get Pi4J working on it!

If you're working on similar projects or have experience with Java on RISC-V, I'd love to hear about it. Feel free to reach out through Mastodon or the Foojay.io community.

First Test of Java on the Orange Pi (ARM and RISC-V)

Frank Delporte — Mon, 12 Jan 2026 18:35:45 +0000

As part of my 2026 learning goals around Java on Single Board Computers and RISC-V (see this post about x86 versus ARM versus RISC-V), I've been asking various suppliers to send me evaluation boards. After testing the LattePanda IOTA, I received two boards from OrangePi to evaluate: the OrangePi 5 Ultra (ARM) and the OrangePi RV2 (RISC-V).

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

OrangePi Lineup

OrangePi offers a diverse range of single board computers at various price points. For this table, I focused on the two boards that I received:

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)
OrangePi 5 Ultra	RK3588	ARMv8	Cortex-A76	4	2.0GHz	175$ (8GB)
OrangePi RV2	Ky X1	RISC-V		8	2.0GHz (?)	53$ (4GB)

The OrangePi 5 Ultra is a high-end board with the powerful RK3588 SOC (same chip used in many Android TV boxes and mini PCs), while the OrangePi RV2 is their budget RISC-V with a Kylin X1 processor.

Test Boards

I received two boards, two eMMC modules, and two power supplies. So everything to get me started! But to speed things up, I decided to use SD cards for the Operating System and will use the eMMC modules later, which should give a significant better performance.

OrangePi 5 Ultra

More info about the OrangePi 5 Ultra is available here:

I used the image: Orangepi5ultra_1.0.0_ubuntu_jammy_desktop_xfce_linux6.1.43.

OrangePi RV2

More info about the OrangePi RV2 is available here:

I used the image: Orangepirv2_1.0.0_ubuntu_noble_desktop_gnome_linux6.6.63.

Getting Started

Hardware Setup

Both boards arrived well-packaged. The OrangePi 5 Ultra looks almost identical as a Raspberry Pi 5. It has an excellent build quality with very similar connecters, except it has a full HDMI in and out, compared to two micro HDMI out on the Raspberry Pi 5. The RV2 has again the same size as a Raspberry Pi, but with a completely different port layout and only 26 GPIO pins compared to 40 on the Raspberry Pi 5 and OrangePi 5 Ultra. Both boards have a detachable Wi-Fi antenna-cable.

Installation for both followed a similar pattern: download the Ubuntu image from OrangePi's Google Drive, flash to microSD, and boot.

Java Installation and Testing

OrangePi 5 Ultra (ARM)

For the ARM-based 5 Ultra, I wanted to test the full Java stack including JavaFX. With SDKMAN I could quickly install a JDK and JBang.

Installing SDKMAN

Run the curl command to install SDKMAN, and open a new shell, or use the source command to activate SDKMAN:

curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"
sdk version

SDKMAN provides easy access to multiple Java distributions and versions. For this board, I installed Azul Zulu 25 with JavaFX:

sdk install java 25.0.1.fx-zulu
sdk install jbang

Testing with Pi4J Examples

I cloned my JBang project from the Pi4J repositories to run some tests:

git clone https://github.com/Pi4J/pi4j-jbang.git
cd pi4j-jbang

The plain Java examples worked perfectly. The JavaFX example also ran smoothly, demonstrating that the RK3588 GPU is well-supported in Ubuntu. The board feels very responsive with these first, quick tests.

OrangePi RV2 (RISC-V)

The RV2 was more challenging, as expected with RISC-V hardware.

Java Installation

SDKMAN doesn't yet have RISC-V support to install Java. I made a GitHub issue and first pull request, and will try to get this moving. I hope this will help more Java developers to experiment with RISC-V.

For now, the Ubuntu repositories are the way to go:

sudo apt update
sudo apt upgrade
sudo apt install openjdk-25-jdk

This installed OpenJDK 25 for RISC-V (but without JavaFX dependencies).

Testing Basic Java

I ran the same JBang examples that worked on the OrangePi 5 Ultra. Plain Java code executed without issues, but JavaFX examples failed as expected due to missing dependencies. The same issues with Pi4J are reported regarding user rights, something to investigate in the future.

OrangePi RV2 Performance Comparison

Phoronix conducted comprehensive benchmarks comparing the OrangePi RV2 with Raspberry Pi boards. Their Java SciMark 2.2 tests show the RV2 is 2-7 times slower than the Raspberry Pi 5 depending on the workload.

The overall benchmark results paint a clearer picture:

The RV2 scores lower than both the Raspberry Pi 4 and 5 across most tests. This isn't a surprise because RISC-V is still maturing, and the Ky X1 is an early implementation. The 8 cores help with parallel workloads, but single-threaded performance lags behind ARM equivalents.

In contrast, the OrangePi 5 Ultra performs exceptionally well and should be comparable to the Raspberry Pi 5 performance thanks to the powerful RK3588 SOC. But that's an other personal goal for 2026, setting up a good benchmark to compare Java performance on various boards...

Conclusion

These two boards represent vastly different approaches. The OrangePi 5 Ultra is a premium board that competes directly with high-end single-board and desktop computers for many tasks. It's more expensive than a Raspberry Pi but delivers impressive performance. Thanks to SDKMAN and the various Java tools that work just as wel as on any other type of Linux computer, including JavaFX, it's an attractive platform for serious development work for a low price.

The OrangePi RV2, on the other hand, is clearly a budget RISC-V board for experimenters. The performance doesn't match ARM boards in the same price range (yet?), but that's not really the point. It's an affordable way to explore RISC-V, contribute to ecosystem development, and prepare for a future where RISC-V becomes more competitive.

For Java developers specifically: if you need a powerful ARM board for actual work, the OrangePi 5 Ultra is worth considering. If you're curious about RISC-V and want to help mature the Java ecosystem on this architecture, the RV2 provides a low-cost entry point.

My testing continues with more RISC-V boards coming soon! If you're working on similar projects or have experience with Java on OrangePi boards, I'd love to hear about it. Feel free to reach out through Mastodon or the Foojay.io community.