DEV Community: Frank Delporte

Sheetmusic4J 0.0.3: ABC, Guitar Pro, Engraving Improvements

Frank Delporte — Thu, 30 Jul 2026 09:20:46 +0000

Last week I introduced Sheetmusic4J, a Java(FX) library to render and interact with sheet music. That first 0.0.1 release was really a question more than a product: is there any interest in a native Java(FX) sheet music library before I invest more time in it? So I shared it on social media and waited to see what would come back.

The answers arrived faster than I expected. And they gave me more homework...

Two Comments, Two New Formats

I posted about the release on LinkedIn, and almost immediately two comments landed with the same kind of challenge: "Nice, but does it support ABC notation?" and "What about Guitar Pro files?"

That's exactly the feedback loop I hoped the 0.0.1 release would trigger. The whole point of shipping something small and early is to find out where people actually want it to go, instead of guessing. So I took the challenge, wrote plans in Theia IDE with the @architect and followed up with the @Coder. And now, one week later, Sheetmusic4J 0.0.3 is out with support for both formats, plus a lot of polish on how the notation actually looks on the staff. There is also a 0.0.2, but that has a bug which don't correctly load the abc-files...

ABC Notation, In and Out

Requested by Peter De Coninck.

The headline of this release is ABC notation support: the core module can now both read and write .abc files.

If you've spent time around folk and traditional music, you know ABC. It's a compact, text-based format where an entire tune fits in a few lines of plain text that you can paste into an email, a forum post, or a tune database. It's the exact opposite of MusicXML: terse and human-writable where MusicXML is verbose and tool-oriented. And there are decades of freely shared ABC tunes out there to read.

Here's what a small tune looks like:

X:1
T:Speed the Plough
M:4/4
L:1/8
K:G
|:GABc dedB|dedB dedB|c2ec B2dB|c2A2 A2BA|

The new AbcReader and AbcWriter parse into and generate from the same Score model as everything else, so once a tune is loaded, the engraving, JavaFX rendering, and MIDI export all just work. Coverage already goes well beyond the basics: keys and modes, unit note length, meter, tuplets, ties and slurs, grace notes, decorations like staccato and rolls, barline styles, repeats and 1st/2nd endings, guitar chord symbols, lyrics, and multi-line titles, all backed by round-trip tests.

And because ScoreFile dispatches on the file extension, most applications never touch the reader or writer directly:

// Import: build a Score from an ABC tune
Score score = ScoreFile.load(Path.of("speed-the-plough.abc"));

// Export: write a Score back out as ABC
ScoreFile.save(score, Path.of("speed-the-plough-copy.abc"));

ABC is a big enough format that not every corner is covered yet, so real-world tunes that don't render correctly are exactly the kind of bug report I want.

Guitar Pro: An Experiment

Requested by Soheil Rahsaz.

The second new format is more of an experiment. Sheetmusic4J can now do basic import of Guitar Pro 7/8 files (.gp, load only).

I want to be upfront about what this is. Unlike MusicXML, MIDI, and ABC, Guitar Pro is not an open format. There's no published specification, and this importer is built on the community's documented reverse-engineering of the modern GPIF format, the XML document tucked inside the .gp ZIP archive. It reads that with the JDK only, no third-party dependency. The older binary formats (.gp3, .gp4, .gp5, .gpx) are not handled, and there's no saving back.

// Import a Guitar Pro 7/8 file (load only)
Score score = ScoreFile.load(Path.of("song.gp"));

I added it deliberately early, because I genuinely don't know yet how people would want to use Guitar Pro files here. Is rendering them as standard notation enough, or is tablature-specific rendering the whole point? That's the kind of thing I'd rather learn from real use than guess at. If you have a use case or a file that doesn't import cleanly, let me know on GitHub.

Better-Looking Engraving

The rest of this release is behind-the-scenes work of making the notation look right. Some of the improvements:

Grace notes now render as proper small flagged/beamed notes with a connecting curve, and their beam follows the pitch contour of the run. Still not perfect, but a lot better than in the first release.
Distinct flag glyphs for 32nd/64th/128th notes, and a real double-whole (breve) notehead.
Ties and slurs sit on the opposite side of the stem by default, and the tuplet bracket disappears when the run already beams cleanly.
Barline styles, repeat dots and voltas; articulations that hug the notehead; chord symbols closer to the staff; and better spacing around titles and accidentals.

There's also a new NoteBackgroundStyle in the FX viewer to configure the highlight box drawn behind a note (handy for play-along views), and a fix for a crash on very large scores by rendering through a windowed canvas instead of one oversized texture.

Under the Hood

The demo app got reorganized and gained a standalone strip play-along demo, the library now logs through SLF4J, the MusicXML reader correctly merges multiple <attributes> blocks per part instead of overwriting, and MIDI import produces fewer spurious rests.

Still 0.0.x, Still Listening

This is version 0.0.3, not a stable release. The API and the rendering can still change, and that's the point of publishing this early. The first release asked whether anyone cared; this one is what happened when a couple of people answered in the comments.

The full list of changes is in the release notes, and the code examples show how to get started. If you try it and hit a rendering difference, or you want a format that isn't there yet, issues and feedback on GitHub are exactly what shapes where this goes next. As it turns out, so is a comment on LinkedIn.

Introducing Sheetmusic4J, a Java(FX) Library to Render and Interact with Sheet Music

Frank Delporte — Fri, 24 Jul 2026 12:01:13 +0000

I'm building MelodyMatrix with my son, an application to look at and play along with music. The app already shows a song in different views: falling blocks, chords, guitar views, and many more. Now we want a Learn section, a view that helps someone practice piano by following the actual sheet music while it plays.

A static PDF of the sheet doesn't work for that. Great PDF viewer components exist for JavaFX, but a PDF has no connection to what's playing. Nothing highlights the current note, nothing marks the current position in the song. I looked for a JavaFX library that renders sheet music and lets code interact with it: jump to a position, highlight a note, follow playback. I couldn't find one, so I built it.

Same Approach as Lottie4J

The problem matched one I'd already solved. With Lottie4J, I ran into the same gap: solid animation players exist for the browser and mobile, none for JavaFX. Sheetmusic4J follows the same path: an open file format on one side, a JavaFX rendering component on the other, with AI doing a large part of the implementation work.

To be clear, this isn't vibe coding. I define the tasks, describe what I want to achieve, review what comes back, and iterate from there. The library wouldn't exist this fast without that collaboration, but the direction and the decisions stay mine.

Built on MusicXML

Sheetmusic4J reads MusicXML, an open standard for representing sheet music. MIDI stores notes and timing, MusicXML stores a lot more: how a piece is structured, how it should look on the page, lyrics under a melody line for a song with a singer. MusicXML also ships an official set of example files, and I use those to compare what Sheetmusic4J renders against the reference PDF for each file.

Notation itself follows the SMuFL standard for music fonts. Sheetmusic4J currently renders with the Bravura font. I haven't wired up font swapping yet, that's still on the list, but SMuFL makes it possible to support other notation fonts later.

The image above comes straight from the library and maps MusicXML terms to the class names in the Java model and to the layout terms used internally. I'm not a musician, despite years at music school long ago, so I built this reference for myself first. It also gives anyone reporting an issue a shared vocabulary to point at the exact element that's wrong. Check the NOTATION_ELEMENTS.md file on GitHub for more info and a table showing the link between MusicXML elements and how they are used in the library code.

Open Sheet Music Display already renders MusicXML in the browser and served as a reference here, the same role the official Lottie web player played for Lottie4J. A WebView could show the same result inside MelodyMatrix, but a WebView doesn't give me a way to talk to the rendering from JavaFX code. Sheetmusic4J does: it exposes the hooks to move a marker, highlight a note, and drive the view from a MIDI stream, which is exactly what MelodyMatrix needs to sync a piano performance with the sheet.

Four Repositories, One Library

Everything lives in the sheetmusic4j organization on GitHub, with the library project structured close to Lottie4J:

Core: reads and writes MusicXML and MIDI files.
Engraver: turns that raw data into the layout of a sheet, with no JavaFX dependency.
FX Viewer: the JavaFX component applications use to show a sheet, including a full-page sheet view and a horizontal strip view.
Demo: a test application for the other three modules.

The demo app renders the same MusicXML file two ways side by side: a static PDF (using Derek Lemmerman's PDF viewer component) next to the Sheetmusic4J FX Viewer. The PDF stays fixed to its page size. The FX Viewer reflows the layout as the window resizes, which occasionally shifts a line differently than the PDF does. The demo also includes tools to simulate playback and highlight notes, without any sound, purely to test the visual sync. A diff tab compares the FX Viewer output pixel by pixel against the reference PDF. It surfaces real differences, though I'm still figuring out how useful that comparison is given that a static PDF and an interactive viewer solve different problems.

Using the Library

Add the FX Viewer dependency to a JavaFX project:

<dependency>
    <groupId>com.sheetmusic4j</groupId>
    <artifactId>fxviewer</artifactId>
    <version>0.0.1</version>
</dependency>

Load a MusicXML file into a sheet view with a few lines of code:

Score score = ScoreFile.load("path/to/song.musicxml");

SheetView sheetView = new SheetView();
sheetView.setScore(score);

stage.setScene(new Scene(new ScrollPane(sheetView), 900, 600));
stage.show();

The FX Viewer module also ships a StripView for a horizontal, scrolling layout of the same score.

Version 0.0.1, and What's Next

This first release carries version 0.0.1, not a stable release. A lot of the API and the rendering can still change. From here, MelodyMatrix's Learn section drives most of the requirements: following a marker across the sheet, highlighting the note currently played, keeping the view in sync with MIDI input from a real piano.

If you try it and hit a rendering difference, open an issue in the GitHub repository with the MusicXML file and a screenshot of what you expected versus what you got. That's exactly the kind of report that moved Lottie4J forward fast, and I expect it works the same way here. Check the code, the docs, and the demo app on sheetmusic4j.com. Use the dependency from Maven or fork the repository, and let me know what you build with it.

First Test of Java on Banana Pi (ARM and RISC-V), Plus a Blinking LED with Pi4J

Frank Delporte — Thu, 16 Jul 2026 14:58:44 +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)
BeagleBoards (ARM and RISC-V)
Java 25 on BeagleV-First
In this post: Banana Pi's

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

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.

Banana Pi

Here's how the Banana Pi's I received, compare to some of the Raspberry Pi's. If you compare the Raspberry Pi prices with my earlier articles from +-6 months ago, you'll see that the prices have gone up a lot. The shortage of memory chips is really a problem and making these single-board-computers less attractive...

The Banana Pi BPI-M4 Zero was 44€ earlier this year, but now at 148€! The BPI-F3 went from 84€ to 214€...

Board	SOC	Type	CPU	Cores	Speed	Early 2026	July 2026
Raspberry Pi 4	BCM2711	ARMv8	Cortex-A72	4	1.8Ghz	68€	128€ (4GB)
Raspberry Pi 5	BCM2712	ARMv8	Cortex-A76	4	2.4Ghz	79€	144€ (4GB)
Raspberry Pi Zero 2	BCM2710A1	ARMv8	Cortex-A53	4	1Ghz		21€ (0.5GB)
Banana Pi BPI-M4 Zero	H618	ARMv8	Cortex-A53	4	1.5Ghz	44€	148€ (4GB+32GB)
Banana Pi BPI-F3	SpacemiT K1	RISC-V		8		84€	214€ (16GB)

First Impressions

Banana Pi suffers from the same problem as a lot of single-board-computer suppliers. They make great hardware but forget the user experience to get started... There is no tool available to select the board and create an SD card like you can do with the Raspberry Pi Imager tool. So you have to search through the documentation, ignore some broken links, and search further to find the right image...

Below are the links I found with OS images for the Banana Pi boards and burned them to an SD card with the Raspberry Pi Imager tool. In the "Device" step select "No filtering", and in the "OS" step select "Other" and browse to the image file you have downloaded (and unzipped).

Banana Pi BPI-M4 Zero

Banana Pi BPI-M4 Zero is the successor model of BPI-M2 Zero. The SOC is upgraded to Allwinner H618 quad-core A53 . The memory is upgraded to 2G LPDDR4, and 8G eMMC onboard . It supports 5G WiFi and BT, and the USB interface has also been upgraded to type-C. It has the same form factor and 40-pin connector as the Raspberry Pi Zero W, and it will fit most Zero W cases and accessories.

Product page
Documentation
Getting Started
Operating System
- I used "20241011_Bananapi-Armbian_24.8.2_Bpi-m4zero_ubuntu22.04_jammy_legacy_5.4.125_xfce_desktop.zip"

Banana Pi BPI-F3

Banana Pi BPI-F3 is a industrial grade RISC-V development board, it design with SpacemiT K1 8 core RISC-V chip, CPU integrates 2.0 TOPs AI computing power. 2/4/8/16G DDR and 8/16/32/128G eMMC onboard.2x GbE Ethernet prot, 4x USB 3.0 and PCIe for M.2 interface, supprt HDMI and Dual MIPI-CSI Camera.

Product page
Documentation
Getting Started
Operating System
- Select the image ending in "bianbu-k1-xxx.img.zip"
- I used "bianbu-25.04-desktop-k1-v3.0.1-release-20250815185656.img.zip"

Testing with Java and Pi4J

I started with a lot of reserves... Both OS images are pretty outdated (2024 and 2025), so I'm wondering what I will find when I boot the boards. I also have no idea if the Banana Pi BPI-F3 RISC-V board will run Java 25, as it is a very new board and the OS image is already a bit outdated.

Banana Pi BPI-M4 Zero

The Zero boots in terminal mode, and after the first boot asks to create a root password, user account, and WiFi credentials. After that, it's ready to be used and accessible via SSH. I used a USB-C dongle to connect keyboard, mouse, and network to get started quickly. After doing the usual steps I used on the previous boards I tested, I can confirm that Java runs fine on the Banana Pi BPI-M4 Zero. I installed Java 25 (25.0.3-zulu) and JBang, and ran the HelloWorld.java and JsonParsing.java examples from the Pi4J JBang repository. The result is shown in the video.

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.3-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 basic
java HelloWorld.java
jbang JsonParsing.java

I also executed my SBC Java benchmark test so we can compare the performance of this board with other single-board-computers. Results below...

Pi4j on the Banana Pi Zero

In the documentation of th Banana Pi BPI-M4 Zero I found a GPIO table that looks similar to the 40-pin layout of the Raspberry Pi. And as we are running the same kind of Linux used in the Raspberry Pi OS, we should be able to use Pi4J V4, based on the Foreign Function and Memory API (FFM API) to access the GPIO pins. I tried to run jbang RgbLed.java from the Pi4J JBang repo.

Sidenote: this board comes without a header, so I soldered a 40-pin header but struggled a lot! For some odd reason, the solder doesn't stick to the board. So it took me a lot of time and removing solder that got stuck to two pins and then trying again. I finally got it done, but it was a lot of work and hope the soldering is good enough to make a reliable connection.

After some struggling with the user rights, using a script from the Pi4J OS repository, I got passed exceptions thrown by the FFM plugin in Pi4J, but still got blocked with the following output. Probably a mismatch between GPIO addresses, or an outdated Linux kernel, something to figure out later... It's also strange that Pi4J recognizes this board as a Raspberry Pi 1 Model B, while it is a Banana Pi BPI-M4 Zero. Seems this Banana Pi has the same board code as the Raspberry Pi 1 Model B...

$ jbang RgbLed.java 
[main] INFO com.pi4j.Pi4J - Pi4J library build info:
[main] INFO com.pi4j.Pi4J -     Version: 4.0.2
[main] INFO com.pi4j.Pi4J -     Timestamp: 2026-06-08T10:01:34Z
...
[main] INFO com.pi4j.boardinfo.util.BoardInfoHelper - Detected OS: Name: Linux, version: 5.4.125-legacy-sunxi64, architecture: aarch64
[main] INFO com.pi4j.boardinfo.util.BoardInfoHelper - Detected Java: Version: 25.0.3, runtime: 25.0.3+9-LTS, vendor: Azul Systems, Inc., vendor version: Zulu25.34+17-CA
[main] INFO com.pi4j.boardinfo.util.BoardInfoHelper - Detected board type MODEL_1_B by code: 0003
[main] INFO com.pi4j.context.impl.DefaultContext - Detected board model: Raspberry Pi 1 Model B
[main] INFO com.pi4j.context.impl.DefaultContext - Running on: Name: Linux, version: 5.4.125-legacy-sunxi64, architecture: aarch64
[main] INFO com.pi4j.context.impl.DefaultContext - With Java version: Version: 25.0.3, runtime: 25.0.3+9-LTS, vendor: Azul Systems, Inc., vendor version: Zulu25.34+17-CA
...
[main] INFO com.pi4j.plugin.ffm.providers.gpio.FFMDigitalOutput - /dev/gpiochip0-23 - setting up DigitalOutput BCM...
Exception in thread "main" com.pi4j.exception.Pi4JException: Error during call to method 'call' with data '[9, 3238048773, LineInfo{name=()[], consumer=()[], offset=23, numAttrs=0, flags=0, attrs=[]}]': Invalid argument (22)
    at com.pi4j.plugin.ffm.common.ioctl.IoctlNative.call(IoctlNative.java:106)
    at com.pi4j.plugin.ffm.providers.gpio.FFMDigitalOutput.initialize(FFMDigitalOutput.java:55)
    at com.pi4j.plugin.ffm.providers.gpio.FFMDigitalOutput.initialize(FFMDigitalOutput.java:24)
    at com.pi4j.registry.impl.DefaultRuntimeRegistry.add(DefaultRuntimeRegistry.java:95)
    at com.pi4j.registry.impl.DefaultRegistry.add(DefaultRegistry.java:103)
    at com.pi4j.plugin.ffm.providers.gpio.FFMDigitalOutputProviderImpl.create(FFMDigitalOutputProviderImpl.java:25)
    at com.pi4j.plugin.ffm.providers.gpio.FFMDigitalOutputProviderImpl.create(FFMDigitalOutputProviderImpl.java:12)
    at com.pi4j.io.gpio.digital.DigitalOutputProvider.create(DigitalOutputProvider.java:58)
    at RgbLed.main(RgbLed.java:38)
Caused by: com.pi4j.exception.Pi4JException: Error during call to method 'call' with data '[9, 3238048773, LineInfo{name=()[], consumer=()[], offset=23, numAttrs=0, flags=0, attrs=[]}]': Invalid argument (22)
    at com.pi4j.plugin.ffm.common.Pi4JNativeContext.processError(Pi4JNativeContext.java:58)
    at com.pi4j.plugin.ffm.common.ioctl.IoctlNative.call(IoctlNative.java:103)
    ... 8 more

After some researching, I found a newer OS for this board and downloaded a version with Xfce desktop from here. With this newer version of the OS, and the correctly configured user rights, we get another error. That's progress! ;-)

$ jbang RgbLed.java 
...
[main] INFO com.pi4j.boardinfo.util.BoardInfoHelper - Detected OS: Name: Linux, version: 6.18.33-current-sunxi64, architecture: aarch64
...
[main] INFO com.pi4j.context.impl.DefaultContext - With Java version: Version: 25.0.3, runtime: 25.0.3+9-LTS, vendor: Azul Systems, Inc., vendor version: Zulu25.34+17-CA
...
[main] INFO com.pi4j.runtime.impl.DefaultRuntime - Pi4J context/runtime successfully initialized.
[main] INFO com.pi4j.plugin.ffm.providers.gpio.FFMDigitalOutput - /dev/gpiochip0-23 - setting up DigitalOutput BCM...
Exception in thread "main" com.pi4j.exception.Pi4JException: Error during call to method 'call' with data '[9, 3260068871, LineRequest{offsets=[23], consumer=(pi4j.FFMDigitalOutput)[112, 105, 52, 106, 46, 70, 70, 77, 68, 105, 103, 105, 116, 97, 108, 79, 117, 116, 112, 117, 116], config=LineConfig{flags=8, numAttrs=0, attrs=[]}, numLines=1, eventBufferSize=0, fd=0}]': Unknown error 517 (517)
    at com.pi4j.plugin.ffm.common.ioctl.IoctlNative.call(IoctlNative.java:106)
    at com.pi4j.plugin.ffm.providers.gpio.FFMDigitalOutput.initialize(FFMDigitalOutput.java:64)
    at com.pi4j.plugin.ffm.providers.gpio.FFMDigitalOutput.initialize(FFMDigitalOutput.java:24)
    at com.pi4j.registry.impl.DefaultRuntimeRegistry.add(DefaultRuntimeRegistry.java:95)
    at com.pi4j.registry.impl.DefaultRegistry.add(DefaultRegistry.java:103)
    at com.pi4j.plugin.ffm.providers.gpio.FFMDigitalOutputProviderImpl.create(FFMDigitalOutputProviderImpl.java:25)
    at com.pi4j.plugin.ffm.providers.gpio.FFMDigitalOutputProviderImpl.create(FFMDigitalOutputProviderImpl.java:12)
    at com.pi4j.io.gpio.digital.DigitalOutputProvider.create(DigitalOutputProvider.java:58)
    at RgbLed.main(RgbLed.java:38)
Caused by: com.pi4j.exception.Pi4JException: Error during call to method 'call' with data '[9, 3260068871, LineRequest{offsets=[23], consumer=(pi4j.FFMDigitalOutput)[112, 105, 52, 106, 46, 70, 70, 77, 68, 105, 103, 105, 116, 97, 108, 79, 117, 116, 112, 117, 116], config=LineConfig{flags=8, numAttrs=0, attrs=[]}, numLines=1, eventBufferSize=0, fd=0}]': Unknown error 517 (517)
    at com.pi4j.plugin.ffm.common.Pi4JNativeContext.processError(Pi4JNativeContext.java:58)
    at com.pi4j.plugin.ffm.common.ioctl.IoctlNative.call(IoctlNative.java:103)
    ... 8 more

On a Raspberry Pi, the numbers you pass to Pi4J directly match the SoC's own "BCM" GPIO numbering, so pin 16 on the header is simply BCM 23, no translation needed. The Banana Pi M4 Zero uses a different SoC (Allwinner H618) with its own GPIO controller and numbering scheme, so that shortcut doesn't apply, even though the board has the same 40-pin header layout as a Raspberry Pi Zero.

The first clue was Banana Pi's own pinout table, which lists physical pin 16 as PI15 = GPIO bank I, pin 15. Allwinner chips group their GPIOs into lettered banks of 32 pins each (PA0-PA31, PB0-PB31, and so on — see linux-sunxi.org/GPIO for the general convention), and the Linux kernel exposes this hardware as character devices under /dev/gpiochip*. Running gpioinfo on the board showed two chips: gpiochip0 with 32 lines, and gpiochip1 with 288 lines. 288 is exactly 9 banks of 32, which matches banks A through I. This indicates that gpiochip1 is the controller behind the 40-pin header, not gpiochip0.

$ sudo apt install -y gpiod
$ gpioinfo
gpiochip0 - 32 lines:
    line   0:      unnamed       kernel   input  active-high [used]
    line   1:      unnamed       kernel   input  active-high [used]
    line   2:      unnamed       unused   input  active-high 
    ...
gpiochip1 - 288 lines:
    line   0:      unnamed       unused   input  active-high 
    line   1:      unnamed       unused   input  active-high 
    line   2:      unnamed       unused   input  active-high 
    ...

To find the pin number to use in the code, we need to do some calculation: the index of the bank (A=0, B=1, C=2, ... I=8) multiplied by 32, plus the pin number within that bank, to calculate the absolute line offset on the chip. For PI15, that's 8 × 32 + 15 = 271.

We can verify this with libgpiod, a command-line tools to toggle GPIO lines. As we already installed gpiod, we can use gpioset to set a line high or low. For example, to toggle the red LED connected to physical pin 16, we can run:

$ gpioset gpiochip1 271=1   # Red on
$ gpioset gpiochip1 271=0   # Red off

The red LED turned on and off, confirming line 271 on gpiochip1 really is physical pin 16. I repeated the same process for green (PI16 → line 272) and blue — except blue's original pin (physical pin 22) turned out to be a 3.3V power pin on this board, not a GPIO at all. So I moved that wire to a real GPIO pin (physical pin 23, PH6, bank H → 7 × 32 + 6 = 230) before it could work.

Color	Physical pin	Offset (gpiochip1)
Red	16	271
Green	18	272
Blue	23 (moved from 22)	230

After testing these values again with gpioset, I could modify the JBang RgbLed.java script. We need to add .bus(1) to target gpiochip1, and change the BCM values with .bcm(271). These are the lines to be added/changed in the original code:

import com.pi4j.io.gpio.digital.DigitalOutput;
import com.pi4j.io.gpio.digital.DigitalState;

...

// Connect a LED to PIN 16 = gpiochip1 line 271
private static final int GPIO_RED = 271;
// Connect a LED to PIN 18 = gpiochip1 line 272
private static final int GPIO_GREEN = 272;
// Connect a LED to PIN 23 = gpiochip1 line 230 (moved from PIN 22, which is 3.3V, not a GPIO pin on this board)
private static final int GPIO_BLUE = 230;

void main() throws Exception {
    // Initialize the Pi4J context
    var pi4j = Pi4J.newAutoContext();

    // Initialize the three LEDs on gpiochip1 (this board's main GPIO controller)
    var ledRed = pi4j.create(DigitalOutput.newConfigBuilder(pi4j)
            .id("red").name("Red LED").bus(1).bcm(GPIO_RED)
            .shutdown(DigitalState.LOW).initial(DigitalState.LOW));

    var ledGreen = pi4j.create(DigitalOutput.newConfigBuilder(pi4j)
            .id("green").name("Green LED").bus(1).bcm(GPIO_GREEN)
            .shutdown(DigitalState.LOW).initial(DigitalState.LOW));

    var ledBlue = pi4j.create(DigitalOutput.newConfigBuilder(pi4j)
            .id("blue").name("Blue LED").bus(1).bcm(GPIO_BLUE)
            .shutdown(DigitalState.LOW).initial(DigitalState.LOW));
    ...
    // Keep the remaining code the same
}

Now executing jbang RgbLed.java finally worked, and the RGB LED started blinking in the expected colors. Success! This is my very first working Pi4J example on a non-Raspberry Pi board!!! One of my 2026-goals is achieved :-)

Banana Pi BPI-F3

The Banana Pi BPI-F3 boots in desktop mode! So that's a lot nicer for a first test ;-) As this board has a RISC-V processor, we can't use SDKMAN to install Java as we learned from experiments with other RISC-V boards before. So I installed openjdk-25-jdk with apt, but to my surprise, this installed an ea (Early Access) version. Maybe because the OS is outdated and got stuck on older JDK releases? Anyhow, I could run the HelloWorld.java and JsonParsing.java examples again without a problem, and ran the SBC benchmark.

Benchmark Results

To have a fair comparison in the benchmarks, I also ran one on a Raspberry Pi Zero 2 as this is the closest competitor to the Banana Pi BPI-M4 Zero. The full results are available on the SBC Java benchmark page, where you can compare them with the other boards I tested before.

Some highlights:

The Banana Pi BPI-M4 Zero beats its direct rival, the Raspberry Pi Zero 2, on every single benchmark. fj-kmeans finished in 64.8s on the BPI-M4 Zero, while the Raspberry Pi Zero 2 didn't even finish within the 10-minute timeout. On the four benchmarks both boards did complete, the BPI-M4 Zero was 35-47% faster, e.g. mnemonics (31.1s vs 58.3s) and future-genetic (23.6s vs 41.6s).
The tiny, cheap BPI-M4 Zero even outran the pricier BeagleY-AI on all five shared benchmarks, by 5% (fj-kmeans) up to 24% (future-genetic). Not bad for the smallest and cheapest board in the whole comparison!
On the RISC-V side, the BPI-F3 is roughly in the same league as the OrangePi RV2 (within 2-5% of each other on every benchmark), and clearly ahead of the older BeagleV-Fire, which timed out on fj-kmeans, mnemonics, and par-mnemonics altogether. On the benchmarks BeagleV-Fire did finish, the BPI-F3 was 2.6-2.8x faster.
Compared to the StarFive VisionFive 2 Lite, the BPI-F3 is almost twice as fast on the heavily multi-threaded fj-kmeans (33.0s vs 62.3s), but the VisionFive 2 edges ahead by 10-17% on the more single-threaded scala-kmeans and future-genetic tests.
Two benchmarks, akka-uct and db-shootout, failed to complete on the BPI-F3. Considering the outdated Bianbu OS image, take these RISC-V numbers with a grain of salt.

Conclusion

Performance-wise, the Banana Pi's are a pleasant surprise! The BPI-M4 Zero, the cheapest and smallest board in this whole comparison, if you take the amount of memory and eMMC into account, outran both its direct rival, the Raspberry Pi Zero 2, and the pricier BeagleY-AI on every single benchmark. And the BPI-F3 holds its own on the RISC-V side too, landing right next to the OrangePi RV2 and comfortably ahead of the BeagleV-Fire.

The rough edges are elsewhere. Documentation is scattered across broken links and outdated OS images, the M4 Zero's header needs to be soldered on yourself (and mine didn't go smoothly!), and Pi4J's GPIO first test still throws exceptions I'll need to dig into further. And unlike the boards themselves, the price is no longer a highlight: the memory chip shortage pushed the prices up, but that's similar for all brands.

Still, if you can get past the price and the setup hassle, Java, JBang, and even an early-access JDK 25 all run without problems on these boards. I'll keep digging into the Pi4J GPIO issue and share an update once I've got the it working.

That wraps up this round of my "2026 single-board computer" series! If you're working on similar projects or have experience with Java on Banana Pi (or RISC-V in general), I'd love to hear about it. Feel free to reach out through Mastodon or the Foojay.io community.

A New Website for MelodyMatrix, and What's New in Release 1.1.0

Frank Delporte — Mon, 13 Jul 2026 08:04:34 +0000

Last week was busy for MelodyMatrix. The website got rebuilt from the ground up, and the app itself got a solid release with a handful of new features.

The Website Is Completely New

melodymatrix.rocks used to be one Spring Boot + Vaadin Flow application serving everything: the public pages, the account/admin back office, and the REST API used by the desktop app. That worked, but a Vaadin app isn't a perfect match for a public product site as it's not great for SEO.

So www.melodymatrix.rocks is now a static, multilingual Hugo site, live in 8 languages (English, Dutch, German, French, Italian, Polish, Japanese, Chinese), deployed to GitLab Pages. The Vaadin application still exists, but it's trimmed down to only what actually needs a server: my.melodymatrix.rocks (account, license, teacher/admin back office) and api.melodymatrix.rocks (the public REST API used by the desktop app, plus the Polar.sh license sales webhook). At this moment, both live in the same application, but the plan is to split them into separate microservices whenever that becomes necessary, e.g. if we sell thousands of licenses a day ;-)

The new site pulls in live data at build time instead of duplicating it by hand: a small Python script fetches the current releases and the open-source "thanks" list from the API before every Hugo build, so the Releases page and the credits are never out of sync with what's actually shipped. This way it's easy to keep the app and website in sync, without the need to maintain the same data in two places.

Built the Same Way as Lottie4J

If this sounds familiar, it's because it's the same approach I wrote about for Lottie4J two weeks ago: Theia IDE driving the Claude API, with an @Architect writing a plan and a @Coder executing it in its own scoped session to simplify the Vaadin website. The layout for the website was created with Claude Design which exported it flawless into a Hugo template. Moving the content from Vaadin to the new website, the i18n scaffolding for 8 languages, the data-driven feature/view/tier cards, was done with AI-assisted coding. Let's be honest, this is the new way of working. Still, a lot of manual work for testing, reviewing, improving, etc. But most of the coding work was done with and by the tools. Yes, it cost me a few 100 dollars in Claude credits, but it saved me a lot of time and frustration. For a pet project, with only minimal available time, I wouldn't have achieved this in such a short time.

The same discipline applied: small, well-bounded tasks (one section at a time: navigation, features, downloads, legal pages, translations) instead of one giant prompt, and a fresh session per task rather than one ever-growing conversation.

App Release 1.1.0

While the website was being rebuilt, MelodyMatrix itself also moved forward to version 1.1.0:

Audio spectrum view: a new visualizer added to the set of viewer stages.
Falling/rising note blocks in the Piano view, closer to the "note highway" style many musicians expect from a practice tool.
Improved sync between view, soundfont, and audio playback.
i18n support, with extra languages added to the desktop app itself.
Improved MIDI view and reordered views for a more logical order.
A fixed macOS DMG build step in the release pipeline.

As before, the Viewers module stays open source and the download packages are published through jDeploy via GitHub Releases, with the download page on the new site always pointing at the current build.

What's Next

With the website live and 1.1.0 out, we will be focusing on content improvements. We want to create videos to demonstrate all views and features. And Vik is working on multiple series of lessons that will be integrated in the app to learn to play piano, use jazz chords, etc.

Please take a look at the new website and install MelodyMatrix (it's free for most features). Let us know your remarks and provide feedback about what's bad/great! If you spot a broken translation, a confusing page, or a bug in the app, issues can be reported in the open-source Viewers repository.

My Book 'Java Programming for Raspberry Pi' is Now Available as Softcover and Hardcover on Amazon

Frank Delporte — Fri, 10 Jul 2026 07:20:33 +0000

"Java Programming for Raspberry Pi: A Hands-On Guide to Electronics and IoT Projects" is now available as a softcover and hardcover paper book through Amazon, on top of the Kindle ebook and the pay-as-you-wish version on Leanpub. If you prefer holding a physical book while you're wiring up LEDs and sensors on your Raspberry Pi, that's now possible again.

How it got there

The first version of my book, got published as paper book by Elektor in 2020. At that time, they basically took the Leanpub manuscript, did some minor changes, and printed 1000 copies. As a writer, you get only a few percent of the sales price, so although those 1000 copies sold out, you can still considere it a pet project ;-) After that, Elektor returned me the publishing right for a paper version.

I'm happy to announce, new paper editions are now available! I exported a non-branded version of the manuscript straight from Leanpub and pushed it through Amazon KDP (Kindle Direct Publishing) as a print-on-demand title. I won't pretend it was a smooth ride: reformatting a Leanpub export into something KDP accepts for interior layout and cover specs took several rounds of trial and error. But it is still the shortest and easiest path I found to get a self-published book into a paper form without signing up for a subscription with a print service. You upload once, and Amazon handles printing, shipping, and returns per order.

Amazon runs price reductions on both the softcover and hardcover fairly often, so it's worth keeping an eye on the listing if the current price is higher than you want to pay. Also, make sure to check your local Amazon website to avoid extra import or shipping costs!

Keeping it in sync with Leanpub

The Leanpub version is the one I keep actively updating, and I'll try to push those updates through to the Amazon paper editions too. Re-exporting and republishing through KDP is more manual than a Leanpub update, so the paper book will always trail a bit behind.

That said, the timing works out well. End of 2025 and start of 2026 I did a big rewrite to bring everything up to Java 25 and Pi4J V4. That means this print edition is already current with the state of the ecosystem today, and I don't expect Java, Pi4J, or the Raspberry Pi hardware line to go through equally massive changes again any time soon. So even without frequent paper reprints, this version will stay a solid, up-to-date reference for the next few years, especially if you're someone who just prefers reading from paper instead of a screen.

Where to get it

Where	Link
Softcover (Amazon)	amazon.com
Hardcover (Amazon)	amazon.com
Kindle ebook (Amazon)	amazon.com
Ebook, pay-as-you-wish	leanpub.com

The books page on my website has links for more Amazon regions (UK, DE, JP, CA, BE, NL, ...) and stays the up-to-date overview if these change. The full sources, extra links, and documentation remain free on GitHub.

Closing the Visual Gap Between the Official Lottie Webplayer and Lottie4J

Frank Delporte — Thu, 02 Jul 2026 09:55:07 +0000

A Lottie library is only as good as its output looks. If an animation renders differently in Lottie4J than it does in the official web player, that's a bug, even when no exception is thrown and the code looks correct.

Within the fxfileviewer, there is an app to visually compare the result of the JavaFX player and a webview using the official JavaScript player. Problem is that I was using the JavaFX Web component for this and this doesn't fully support the latest/best version of this player. Based on this app for manual checks, I also created a unit test which is able to loop over a set of files and compare the differences to make sure changes in the code don't break the existing renderer. But I kept struggling with the same test file interactive_mood_selector_ui.json which didn't render correctly, both in the JavaFX view and my web-based view to compare it with.

Over the last weeks the focus has been exactly there: making the JavaFX output match the reference renderer, pixel for pixel (if possible).

Improved Comparison Workflow

The biggest change is not a rendering fix but the way rendering is now verified. The test suite renders the same animation two ways and compares them frame by frame:

The reference side runs the official web player inside a headless Chrome instance. This reference renderer was migrated from lottie-web to dotlottie-wc (thorvg), the engine LottieFiles is standardizing on. The reference images are not generated during the unit test, but as a one-time job on my PC and committed in the test/resources.
The Lottie4J side renders the same file through the JavaFX player.

Now each frame is diffed, instead of every 5 frames before, and measured against a tolerance "floor". When Lottie4J drifts from the reference, a test fails and points at the exact frame. This runs with headless JavaFX on GitHub Actions as described in the post Testing Lottie4J JavaFX Animations in GitHub Actions Without a Display: JavaFX 26 Headless to the Rescue. That turned "this animation looks a bit off" into a concrete, reproducible signal. The goal is to get each file to 99.5% similarity, but that value can be overruled per file. As you can see in the code, the "worst" file is now at 95.2%, and yes, it's still that difficult interactive_mood_selector_ui.json.

     private static final Map<String, Double> PER_FILE_FLOOR_OVERRIDE = Map.ofEntries(
            Map.entry("json/interactive_mood_selector_ui.json", 95.2),
            Map.entry("json/animated_background_patterns.json", 99.2),
            Map.entry("json/angry_bird.json", 98.2),
            Map.entry("json/face-peeking.json", 98.5),
            Map.entry("json/java_duke_flip.json", 95.7),
            Map.entry("json/java_duke_slidein.json", 98.8),
            Map.entry("json/lottie_lego.json", 98.0),
            Map.entry("json/sandy_loading.json", 99.3),
            Map.entry("dot/demo-1.lottie", 99.3)
    );

New real-world test animations, like pi4j.json, foojay-reporter.json and foojay-duke.json, got added so the harness measures against the files I'm actually using.

Rendering Fixes

With the harness in place, the diffs made it obvious where JavaFX and the web player disagreed. The fixes can be grouped into a few areas:

Easing: The lottie-web BezierEaser was ported byte-for-byte into a shared core.helper.BezierEasing, and the arc renderer now clamps the easing solver to prevent bezier divergence, with a bisection fallback for flat-point curves. A full-circle trim path that used to flicker (floating-point precision loss when wrapping the offset) is fixed.
Mattes: Pixel-level matte composition was extracted into a testable static helper, and the inverted-alpha matte type (tt: 2 → INVERTED_ALPHA) is now handled correctly.
Gradients: Alpha and colour stops are merged at the union of their offsets, and linear-RGB gradient stops are densified so colour transitions match the reference.
Blur and blend modes: Gaussian blur was improved, the blend-mode offscreen buffer size is rounded up (ceil) so nothing gets clipped, and the effects renderer was reworked.
Text: Text colour handling and text animation are now correct.

Individually these are small, but together they close a lot of the visible distance between Lottie4J and the official player.

Built with Systematic AI Coding

All of this was implemented with Theia IDE using the Claude API. I learned about Theia IDE during an Eclipse Foundation workshop in Brussels. I wrote about it on Foojay.io: Systematic AI coding, my takeaways.

The takeaways from that article map almost one-to-one onto this batch of work:

Design before prompting, then review the output: The comparison harness is what makes review possible. And the @Architect within Theia IDE was able to run the tests file by file, find differences, write plans, and evaluate the results.
A tight feedback loop beats one big prompt: Failing frame → targeted fix → re-run → next frame. The commit history reads as exactly that rhythm.
Keep sessions scoped and don't fear a restart: The @Architect writes the plan. And then you start a new session and ask the @Coder agent to execute it. Each rendering area (mattes, gradients, blur, text) was tackled as its own well-bounded task rather than one ever-lasting conversation.
Let the tools review too: A round of code improvements came straight out of SonarQube findings.

I committed all the tasks written by the @Architect into the repository so they are available as "history of the project". The most important take-away here isn't that AI wrote the code, but the disciplined process with clear tasks and small iterations, each in a new session.

The Result

Where are we now? Check the images below.

The first screenshot is the test file in the Preview player on the Lottie website. As you can see a lot of gradients are used in the background and around the emojis. Those are the parts I was struggling with...

The second screenshot is the "before". Both the JavaFX and the webview version have a lot of differences. This also means I was using the wrong comparison source images to validate the JavaFX result!

The third screenshot is the "after" which shows a lot of improvements. First and most important, the comparison images from the webview are now pixel-perfect as they get rendered based on the latest version of the official Lottie web player. And you can also see that the JavaFX result is now a really close match! The background gradients are not pixel-perfect yet, and I still see small differences in the text, which confirms the 95% similarity score. But overall, I'm very happy with the improvements!

The Cost

Of course, the AI coding process is not free. Theia IDE luckily is free, but it needs one or more API keys to call AI services. As you can see, I burned a lot of tokens, and budget. But to be honest, I would not have achieved these improvements by myself in such a short time. Actually, I could do my "real work", and have the tools work in the background!

What's Next

I'm happy with the results so will release a new version soon. The same approach with @Architect/@Coder will help me to further improve or fix the library when needed. But first I want to know which visual differences remain based on feedback from the users of the Lottie4J library!

As always, contributions, bug reports, and pull requests are welcome at the Lottie4J GitHub repository. If you have an animation that renders differently than you expect, isolate it, and open an issue with the JSON. That's exactly the kind of case the test flow is built to catch.

From breadboard chaos to a real PCB: designing the Pi4J smoke test board

Frank Delporte — Thu, 25 Jun 2026 09:30:36 +0000

Testing a Java I/O library properly means testing it on real hardware. No mocks, no stubs, just actual pins doing actual things. For Pi4J, that means running the smoke test: a setup with two BMP/BME280 sensors, some GPIO-to-GPIO jumper connections, and a bunch of patience while you untangle the wires for the third time this week.

That last part is what finally pushed us to design a proper PCB. This is the story of board number 0001.

What is the Pi4J smoke test

The Pi4J smoke test is a test project that verifies the Pi4J library works correctly on real Raspberry Pi hardware. It covers the most important communication protocols:

I2C: using a BMP280 or BME280 sensor for air pressure and temperature
SPI: a second BMP/BME280 sensor over SPI
GPIO: several pin-to-pin connections to test PWM output, digital output, digital input, and debounce behaviour

The wiring involves quite a few connections. Two sensors, a T-cobbler breakout board plugged into a breadboard, and a collection of colour-coded jumper wires connecting GPIO pins to each other. It works fine, but "works fine" and "reliable test setup" are not always the same thing.

The problem with the breadboard

Every time someone of the Pi4J sets up the smoke test on a breadboard, something is slightly different. A wire in the wrong column. A jumper that looks seated but is not. A sensor that falls over when you move the board.

This is fine for a quick experiment. It is not great when you want to hand the setup to a contributor, or use it consistently across different hardware revisions of the Raspberry Pi. The goal of a smoke test is to give you a fast, repeatable answer to the question "does this still work". A breadboard that changes shape every session works against that goal.

So we wanted to have a "fixed solution" already for a long time...

Designing the board with EasyEDA

I used EasyEDA Pro for the design. It is a browser-based PCB design tool with a built-in schematic editor, a large component library, and direct integration with JLCPCB for ordering. The learning curve is manageable, especially for a board this straightforward.

I did not do this alone. Jan, a coach from my CoderDojo club in Ieper, helped me convert the breadboard setup into a proper schematic. That turned out to be the right call. There are details in PCB design, like how to connect the sensors, adding the LEDs, component placement, and clearance rules, where experience matters more than enthusiasm. Jan has a lot of hardware-design experience and was happy to share it.

The starting point was the wiring tables from the smoke test documentation. Every connection in those tables needed to end up as a trace or a connector on the board. That gave us a clear scope and made the design process straightforward.

In the schematic you don't have to draw every wire as a line. Instead you use net labels: a pin gets a label like SDA or SCL, and every other pin with the same label is connected to it. The same approach works for both the I2C and the SPI side, and for the ground and 3.3V connections that run across the board. It keeps the schematic readable while still describing every single connection from the wiring table.

From the schematic, EasyEDA can propose a board layout for you. That proposal is only a starting point. I did a lot of fine-tuning on top of it and went back and forth with the Pi4J team before the layout was right. A nice feature here is that you can hover over a net and watch all its connections light up, which makes it easy to validate that, for example, the ground plane and the SPI wires really go where they should. EasyEDA also has a 3D visualization, so you can turn the board around, check it from all angles, and confirm that everything is labeled correctly before ordering anything.

What is on the board

The finished board has a few distinct sections.

The 40-pin GPIO header runs across the middle, with pin numbers printed on both rows. This connects directly to the Raspberry Pi GPIO header. Above the header, a row of SMD resistors and LEDs helps to see if the GPIO-to-GPIO tests are running. They are grouped by the pin ranges they cover: 12-16, 13-15, 16-22, 32-36, 36-37, and 38. Each group maps to one of the test cases in the smoke test wiring table.

On the left side of the board there is an I2C connector for the first BMP/BME280 sensor. On the right side there is an SPI connector for the second sensor.

The board also has mounting holes in all four corners, which means you can actually fix it to something instead of letting it slide around on a desk. And there are two additional 20-pin headers so it's easy to connect a measuring instrument if something seems to be not working as expected.

Board number 0001 is the first one off the production run. The QR code in the top corner is the PCB manufacturer's tracking code.

Ordering the board

The board is manufactured by JLCPCB, which integrates directly with EasyEDA. This is where I ran into some user experience problems. These companies are great at hardware, but the ordering software is confusing the first time you use it. From the schematic view, the only thing you get is an "order the parts" button that drops you on the JLCPCB website without actually starting an order. The real ordering options live in the PCB view, behind a different set of buttons that are not clearly labeled. I ended up chatting with the support team just to figure out which button I needed to press.

Once I found the right place, ordering was easy. The minimum quantity is five boards, which was fine, because I also wanted them assembled and will share with members of the Pi4J team. The only component not in stock was the 40-pin GPIO header, but that is cheap and easy to solder yourself, so it was not a problem.

The package arrived well protected, with each board resting on a piece of foam to protect the headers. The boards came on a larger panel because my design was too small to run through the production machines on its own, so the manufacturer adds extra board material around it. After that it was just a matter of soldering the 40-pin header, which goes straight through and is the easy part.

First results

To make sure nothing had changed in the code, I first ran the existing smoke test on my old breadboard setup with a Raspberry Pi 5, straight from IntelliJ. The run executes about ten tests across the different protocols, including PWM, digital I/O, I2C, and SPI, and the summary reported all ten passing.

Then I connected the new PCB using a flat cable, carefully matching pin 1 on the Raspberry Pi to pin 1 on the board. Using two flat cables means I don't have to keep unplugging connectors directly on the Raspberry Pi, which limits the stress on the Pi's own header. Running the same smoke test, the LEDs started blinking and jumping from one pin group to the next as each test ran, a nice visual confirmation that something is actually happening. And the result was the same: all tests passed.

The connections are solid, the connectors are in the right place, and nothing falls over when you pick it up. That is exactly what you want from a test board.

What Is Next

The plan is to open source the EasyEDA design files and add the board to the Pi4J hardware testing documentation. If there is interest from contributors, it could become an official Pi4J testing accessory, something you can order yourself or build from the files.

If you have feedback on the design, or ideas for what else should go on a future revision, open a discussion on the Pi4J GitHub or find us on Slack.

And yes, CoderDojo coaches know more about PCB design than you might expect.

JavaFX In Action #27 with David Gutierrez about JMathAnim to Create Mathematical Animations

Frank Delporte — Thu, 25 Jun 2026 09:28:01 +0000

The JFX Central Links Of The Week is a great source to discover what is happening in the JavaFX world. One of the projects that caught my eye is JMathAnim, a tool to create mathematical animations built on top of JavaFX. In this interview, David Gutierrez, a mathematician from Spain, walks us through what the project can do and how it came to life.

About David

David Gutierrez is a mathematician who started the JMathAnim project during the COVID lockdown period. By his own admission, he is not a trained developer. He built JMathAnim because he needed a tool that didn't exist in Java yet, and Java was the language he was most comfortable with. He was inspired by Manim, the popular Python library used to create mathematical animations, and decided to build his own equivalent in Java.

His work is a great example of what happens when domain expertise meets just enough programming knowledge: the result is a highly focused, purpose-built tool that does one thing very well. You can follow his work and find examples of his animations on:

About JMathAnim

JMathAnim is a Java library and UI built on JavaFX that lets you create animated mathematical visualizations. The goal is simple: make it easy to build videos that explain mathematical concepts through animation. It's inspired by the kind of content you see on YouTube channels like 3Blue1Brown.

What It Can Do

The library covers a wide range of use cases. You can animate LaTeX-rendered formulas, morphing one expression into another step by step. You can build geometric visualizations, simulate cell growth, generate fractals, and produce videos explaining number theory concepts like base conversion. Everything you see in the animation is defined in code, and the output can be exported directly to a video file, no intermediate steps required.

A particularly nice touch is the built-in code editor, which includes syntax highlighting via RSyntaxTextArea and code completion hints. This makes it accessible to people who want to experiment with the library without setting up a full Java IDE.

Why Ruby in the Code Editor?

One interesting design choice is the use of Ruby as the scripting language inside the built-in editor. The reason isn't mathematical tradition, but it's practical. Ruby's scripting model fits well with the way animation sequences are written, making it a natural fit for the kind of short, expressive scripts you need to define animations. The Java library itself handles all the heavy lifting; Ruby is just the glue layer in the interactive editor.

JavaFX as the Rendering Engine

All rendering in JMathAnim is done on a JavaFX Canvas. LaTeX formula rendering is handled by JLatexMath, and video export relies on JavaCV. The combination gives JMathAnim a capable pipeline from code to finished video.

David is the first to admit that JavaFX had a learning curve, especially since he came at it as a mathematician rather than a developer. But his experience shows that JavaFX is approachable enough that someone without a formal software engineering background can build something genuinely impressive with it.

Explaining Math Visually

One of the most compelling examples shown during the interview is a visualization explaining the conversion from base 10 to base 5. It's a simple concept, but seeing it animated makes it click in a way that a textbook explanation often doesn't. This is exactly the philosophy behind JMathAnim and the channels that inspired it: a well-made animation can communicate in seconds what would take paragraphs to describe in writing.

Video content

00:00 Who is David

00:33 Goal of JMathAnim

01:16 Demo of JMathAnim

04:53 Different ways to create animations in the tool

05:40 Why Ruby is used in the code editor

06:24 More demos

07:16 Demos and info on the website

11:12 JavaFX learning curve

13:46 Libraries used in the project

14:30 Example to explain base 10 to base 5 conversion

16:27 Conclusion

More JFX In Action...

Click here for more posts with JFX In Action videos.

Systematic AI Coding: My Takeaways from the Eclipse Foundation Workshop in Brussels

Frank Delporte — Wed, 24 Jun 2026 08:24:03 +0000

Most developers using AI tools are still guessing. The Eclipse Foundation's first AI Coding Workshop in Brussels was built to change that. It's a brand new format they launched in Brussels, which makes sense: most of the Eclipse event team is based there, right in the heart of Europe. The plan is to take it to more cities from here, so keep an eye out if you want to attend such a workshop in the future. They offered 10 free tickets to share with the BeJUG and Foojay community. And in all honesty, I used one for myself ;-). Jonas Helming from EclipseSource led the workshop, with a fun quiz hosted by Thomas Froment in the afternoon. Here's what I took away.

From Vibe to Systematic

The workshop kicked off with an important framing question: where are we in the AI coding journey? Jonas positioned AI assistance on a scale from 1 (basic code suggestions) to 5 (fully autonomous). We are now at level 4 with tools like Claude Code. Level 5 is approaching when fully cloud-based autonomous agents will be available.

Most developers today are still somewhere in the "vibe coding" zone. Vibe coding is the what, not how approach: you describe what you want, don't look at the generated code too closely (or not all), and focus on the result. It can work well for POCs and low-complexity problems on well-understood domains. But it quickly crumbles once you move into real projects with real complexity.

The fundamental shift the workshop is about, is moving beyond the experimentation phase toward something repeatable and systematic. That's what Jonas calls Systematic AI Coding: understanding how coding agents actually work, and building workflows around them, not just prompting and hoping.

How a Coding Agent Actually Works

One of the most useful sessions was the breakdown of what happens inside a coding agent. It's easy to think of it as a magic box, but the mechanics matter a lot for using it well.

A coding agent takes several inputs: the system message, user messages, assistant responses, your codebase, and any additional context you provide. That context includes things like project context, task context (your plan), and the skills or tools available to the agent. On top of that, you can have optional agent layering, like a model router that picks the right model for the task.

From there, the agent uses tools, calls the LLM, and generates a change set: files, actions, context updates, MCP calls. Everything flows through what Jonas describes as part of the Request Model: tools + messages + tool messages + tool responses. The whole thing boils down to one word: CONTEXT. Context is everything.

A key insight: the LLM is stateless and forgets immediately. Every time it runs, you need to resend the full conversation history for it to understand what happened before. This has a real consequence as the context gets polluted and the cost rises because extra tokens are needed to handle the input. And there's a subtle trap called the "dumb zone": efficiency actually drops before you hit the context window limit. According to some experiments, this can already start at roughly ±40% of the context capacity. So a session that feels like it's still working might already be producing worse results.

The Workflow

Once you understand how agents work, the practical workflow makes a lot more sense. It looks roughly like this:

Your AI Agent generates output, and you need to Review or Decide. From there you have several options: escape (abort), refine (adjust the prompt), redo (start a fresh chat), divide the task further, compact the session, adjust the agent configuration, or commit what's working. Then repeat.

Two important take-aways from Jonas here:

Don't be afraid to throw away changes and start over. A fresh session with a cleaner, better-scoped prompt will often outperform trying to rescue a session that's gone sideways. The bad feeling you may have of "lost coding work" is real, but irrelevant as it's not your work, but done by a tool.
Compact the session yourself, don't rely on the agent to do it. If you let the agent compact automatically, you lose control over what context gets dropped. Doing it yourself means you decide what's kept.

One tip I should follow: when your AI tool is working, don't start another session in another project. Look out the window and think about the actual problem you're solving within the project to better handle the result. Context-switching is expensive for humans too.

Time Changes When You Use AI

Without AI, a developer typically spends roughly 70% of time on design and coding combined, and 30% on debugging. With AI, the split looks very different:

Design: ~30%
Review: ~30%
Debugging: ~35%
Actual AI-generated code: ~5%

The work doesn't disappear, but it shifts. You spend more time thinking, reviewing, and debugging, and less time typing code. This has implications for how you approach a task.

Design before you ever prompt the agent:

Think about the task and if it should be split
Describe your intent with precision
Provide examples, relevant files, and existing implementations
Give the agent a way to validate its own output
Apply the "good friend" metaphor: share the tips and tricks from your own codebase that you'd tell a new colleague

Review isn't optional:

First, find blockers
Decide the follow-up action (refine, redo, split, etc.)
Only if there are no remaining blockers: do a detailed review to finish the task ## Done ≠ Ready

When an agent says it's done, that's not a green light to push. AI-generated code can drift on quality, introduce security risks, and produce "work-slop" that frustrates your coworkers. Before pushing, do a review the way a careful coworker would.

What Companies Need to Enable This

Jonas highlighted a few important requirements that a company needs to provide to its developers if it wants to make systematic AI coding actually happen:

Tools (which cost money)
Time to learn and experiment
Space to experiment and share learnings across the team

That third one is often underrated. Individual experimentation is great, but if there's no mechanism to share what works, the team never levels up together.

On the Eclipse Side

There was also a short quiz by Thomas Froment that covered some Eclipse Foundation projects worth knowing about.

Open VSX is an open-source, vendor-neutral alternative to the Visual Studio Marketplace: an open registry, an open-source project, and a working group.
Theia IDE built on the Theia Platform, ## a modern, AI-native IDE for cloud and desktop. It has many handy AI-tools for developers, like showing every step an agent takes, token usage, a @PR Review agent that you can give a PR number to checkout, build, run, and create a review plan, etc. ## Final Thought

Thanks to the Eclipse Foundation for the free tickets, for the perfect organization, and to everyone from BeJUG and Foojay who joined! This was their first workshop in this format, and I hope they bring it to many more cities soon. Also thanks to the sponsor as they allowed to have a good location with a pro tech team and good food during the whole day.

It was a dense, practical day. This summary is only a small part of all the tips, tricks, hints, pitfalls, and all the other knowledge shared by Jonas, in over four hours. He also has a longer version of this workshop that he gives at companies and other events. If you have the opportunity to meet him or join one of those sessions, you should definitely do!

The biggest shift for me wasn't any single tip but the importance of shifting from vibe to systematic coding. AI coding isn't magic and it isn't a shortcut. It's a different kind of engineering discipline, with its own workflows, its own failure modes, and its own learning curve. The developers who benefit most are the ones who take it seriously, build repeatable processes, and keep their engineering judgment front and center.

This Post Was Co-Authored With Claude Code

Jonas also highlighted that you can use AI tools for much more than coding alone. So, again in all honesty, Claude Code wrote the initial version of this blog during my train ride from Brussels back to Kortrijk. The tool read my handwritten reMarkable notes, exported as a PDF. But, of course, with a full review, rewrite, and fine-tuning by yours truly :-).

A Fresh Design for webtechie.be

Frank Delporte — Wed, 17 Jun 2026 11:48:22 +0000

My website grew over many years into more than 260 posts, 220 videos, 100 podcasts, and 60 presentations. The old design buried most of that under a layout that no longer matched the way I write today. So I rebuilt it from the ground up, and the result puts the content first.

Visit webtechie.be, and you land on a cleaner home page that points you straight to the blog posts, podcasts, and my book. Those are things I spend most time on and deserve more attention. The new design also gives more space to the projects I work on, like Lottie4J, Pi4J, MelodyMatrix, and more. The old site had a lot of content but no clear way to find it. The new one makes it easier to discover what I have to share.

What changed

The redesign touches almost every part of the site. These are the changes you notice first.

A new theme: The whole site moves to a terminal-inspired look that fits the topics I cover: Java, JavaFX, Raspberry Pi, and single-board computers.
More focus on blog posts and podcasts: The home page and navigation push the long-form content forward.
A light and dark switch: You pick the mode you prefer.
A search box: Find any post by keyword without scrolling through archive pages, using a redirect to DuckDuckGo's search engine.
A table of contents: Longer articles show a table of contents, so you jump straight to the section you need.
Better use of tags: The tags got reviewed and have a short introduction.
More RSS feeds: Each section and tag exposes its own feed, so you follow only the parts that interest you.
Open source projects: Highlighted projects that I work on, like Lottie4J, Pi4J, MelodyMatrix, etc.

On top of these, the redesign carries dozens of smaller tweaks to typography, spacing, images, table layouts, and the metadata that drives social sharing.

How Claude Code helped

I built a large part of this redesign together with Claude Design and Code. It handled the repetitive Hugo template work, generated the new theme partials, and helped me track down the small details that make a site feel finished. One example: the social preview images now resolve correctly for every page, which used to break when I shared a link on LinkedIn.

Pairing with an AI assistant on this kind of project changes the pace. I describe what I want, Claude Code writes the template, and I review the result and adjust. The work that used to take an evening of fiddling now takes a focused hour.

Tell me what you think

The site keeps the same address and all the old links still work, so nothing you bookmarked should be broken. Take a look at the new webtechie.be, try the search box and the dark mode, and let me know what works for you and what does not. Your feedback helps me to further improve!

Lottie4J Meets LottieFiles: A Conversation with Naail Abdul Rahman

Frank Delporte — Thu, 04 Jun 2026 09:27:07 +0000

Lottie animations run on Android, iOS, and the web. Getting them working on the JVM is a different story. Lottie4J started as a question: can JavaFX render them without a WebView? That question turned into a library with a first release in March 2026! Since then, I received the first pull requests, recently added headless unit testing with JavaFX 26, and now this: a video conversation with Naail from the LottieFiles team.

I got to sit down with Naail Abdul Rahman, R&D engineer at LottieFiles, the company behind the Lottie animation platform. We talked about where the format came from, where it is going, and what that means for a Java implementation like Lottie4J.

What we talked about

The conversation covers a lot, so here is a quick overview of the topics if you want to jump to a specific part:

00:00 Introduction of Lottie and Naail
04:57 Use cases for Lottie animations, e.g. sprites in games, on ESP32,...
06:21 History of the Android Airbnb player
08:07 About Lottie4J, the Java(FX) player
10:31 Nice Lottie animation examples
14:44 Early history of Lottie, started as Bodymovin
15:54 .json Lottie versus .zip dotLottie formats
18:24 "Example Drive Development" of Lottie4J and headless unit testing with JavaFX 26
19:40 About the Lottie Animation Community (LAC)
22:43 Lottie format documentation with live examples
24:52 Taking a look at the web viewer and other tools on the LottieFiles website
27:20 What the LottieFiles Team Plan offers
29:07 Lottie animations can be exported from After Effects and Figma
30:07 Experiments with AI to generate animations
32:36 LottieFiles Marketspace with free available animations
33:26 What should be the next steps for Lottie4J?
35:50 What's on the LottieFiles roadmap
39:38 Can Lottie4J be validated to be compliant with the community specification?
41:47 Growing interest in Lottie for desktop applications (KDE)
42:53 Where to start if you're interested in Lottie
44:03 Pull requests received for Lottie4J
47:34 Looking into a pending Lottie4J issue
49:04 JavaFX gains more popularity as desktop applications become more important in AI use
50:05 Conclusion

Lottie: from Bodymovin to everywhere

One thing I always find interesting about the Lottie format is that it did not start at LottieFiles. It started as Bodymovin, an After Effects plugin for exporting animations to the web. Airbnb picked it up, built their Android player around it, and the name Lottie stuck. From there the format spread across platforms, communities, and now also into Java.

The open-source specification lives at lottie.github.io, driven by the Lottie Animation Community (LAC). That is the reference Lottie4J works against.

dotLottie: the format worth paying attention to

Most Lottie work today happens with .json files. The dotLottie format (.lottie) is a ZIP container that can hold multiple animations, theming through slots, and interactive state machines, all in one file. It is where things are heading, and it is definitely what I need to add proper support for in Lottie4J.

The difference matters practically. A .lottie file compresses much better than the equivalent JSON, it can bundle assets cleanly, and the slots and states features open up real interactivity that a static JSON animation just cannot do.

What this means for Lottie4J

The conversation pushed me to think concretely about where to take the project next. Three areas stood out as important steps:

Compliance checking against the LAC specification. Naail mentioned this is something the community wants more of. Knowing which features Lottie4J supports accurately gives the community a clear picture of where the project stands.
Better dotLottie support, including multiple animations in a single file and eventually slots and state machines.
The headless JavaFX 26 testing setup I recently documented is a real step forward for CI reliability. That blog post is here if you want the details.

Another important moment in the conversation: Naail noted that interest in Lottie for desktop applications is growing, including from projects like KDE. JavaFX is in good company there! Even more right now, considering the recent announcement by Oracle that are now offering extended JavaFX support. This is something Azul has done for years.

Links from the video

Conclusion

The conversation confirmed something I suspected: Lottie4J is not a niche experiment. Desktop animation is getting serious attention across the Java and Linux ecosystems. If you want to help shape where Lottie4J goes next, head over to lottie4j.com. Pull requests, bug reports, and questions are all welcome in the comments of the video or in the Lottie4J GitHub project.

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