DEV Community: Frank Delporte

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

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

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

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

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

The Test, and Why It Mattered

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

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

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

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

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

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

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

What Changed in JavaFX 26

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

-Dglass.platform=headless

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

The Catch: JavaFX 26 Requires Java 24

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

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

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

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

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

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

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

The GitHub Actions Side

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

mvn test -Pheadless-tests

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

What This Actually Tests

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

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

Would I Recommend This Pattern?

Yes, with some caveats.

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

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

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

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

Links:

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

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

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

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

What Is MelodyMatrix?

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

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

What Is jDeploy?

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

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

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

The Video: Preparing and Triggering the First Release Together

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

Some of the things we covered:

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

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

Why jDeploy, and Why It Is Free

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

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

A Side Note on Lottie4J

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

Timeline

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

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

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

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

dotLottie File Support

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

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

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

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

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

New Player Features

Play Between Markers

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

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

Cropping Support

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

Resizable Player

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

Performance Improvements

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

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

Adaptive Rendering Mode

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

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

Core Model Improvements

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

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

Jackson 3 Upgrade

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

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

Debug Tooling Updates

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

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

Trying It Out

Update your Maven dependency:

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

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

The full list of changes is available on GitHub.

What's Next

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

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