webforJ 26.02 is live! The headline is craftforJ, a visual development environment that runs inside your app and brings a coding agent with it, one that writes Java against the app actually running in front of you. Alongside it, this release opens your views to AI hosts with MCP Apps, adds push notifications and a Card component, brings search to every list component and section labels to AppNav, and makes hotswap the default development loop. See the highlights below, and as always, the GitHub release overview has the complete picture.

The request usually lands vague: leadership wants AI in the app. A day of back-and-forth resolves it into something concrete, a chat feature where users can ask questions and get streaming, well-formatted answers grounded in the app's own domain.

What most tutorials skip is what the feature looks like end to end: the streaming UI, the cancel behavior, the prompt shape, the error surface, and how it all hangs together in a real Java app. This post uses ghost:ai, a small open-source reference project in the built-with-webforJ collection, as the running example. Every code snippet is real code from that project.

Earlier this year, Azul, a Java-focused company, released its 2026 State of Java Survey & Report. Based on responses from over 2,000 Java professionals worldwide, Azul revealed that developers are focused on managing cloud computing, securing apps, and controlling AI output.

Java remains a dominant force in development, with 64% of respondents reporting that more than half of their apps or workloads are built with Java or run on a Java Virtual Machine (JVM). For developers who wish to bring their apps to the browser with minimal changes to their architecture, webforJ offers a strategic approach to modernizing apps quickly and efficiently.

I was building a demo that needed to display an SVG diagram in a webforJ app, and at first I figured it was a straightforward image-loading job. Drop the file on the page, give it a size, done.

Then the real requirements showed up. The diagram was larger than its viewport, so users needed to zoom and pan around it. Its individual sections also represented meaningful things, so the Java app needed to react when a user clicked one. At that point it wasn't really an image anymore, it was an interactive part of the app.

The behavior was self-contained enough to deserve its own component. That turned into SvgViewer, a webforJ composite that displays trusted SVG markup with built-in zoom and pan, and fires a typed Java event with the ID of any region the user clicks.

A lot of what I understand about webforJ, I picked up by building things while writing the documentation. Explaining a feature is one thing. Building something small that actually uses it is where I find out whether I really understood what I was about to explain to everyone else.

That's how it went with custom events. I was writing the events documentation, reached the section on a component firing its own event, and wanted to build one myself before I explained it. I try to build around real scenarios, an actual form, an actual list, something close to what you'd ship, and building it confirmed what the pattern is actually good for: one component announcing and another reacting, all in plain Java without touching JavaScript.

A little while after moving back to the US from working in Germany I was tasked with a colleague of mine to learn some Spring. Bryan and I were in the exact same boat of being totally new to anything more than Java basics, and one of the first tasks we bumped into together was this: take a form on the screen, and wire it up to a Java object that had, of all things, another Java object nested inside of it.

Sounds simple, and it no doubt is to those who are used to Spring and how it works. For us, it was not.

We were told to work with our colleague in Bulgaria to get help, and while he was certainly a Spring expert, the time different meant that we ended up spending days on it. We wrote getter chains, we wrote wrapper DTOs, and we eventually got something working that neither of us really understood. Of course, these days I'd just ask Claude, but he and I hadn't yet been acquainted back then.

If you'd asked me at the time what the "right" way to bind a nested object was, I would have been painfully clueless.

Fast forward to now, and webforJ has this feature baked right in. Past Matthew and past Bryan would have been genuinely thrilled.

webforJ 26.01 is live! The headline is a new frontend bundler: a Bun-powered build step wired into the Maven and Gradle build you already run, letting a Java view pull in npm packages and web components without a separate frontend project or a Node toolchain. Alongside it, this release reworks live reload, adds a new Upload component, brings browser APIs for geolocation, page visibility, and app icon badges, and gives AppNav pinning and search. See the highlights below, and as always, the GitHub release overview has the complete picture.

Recently, I was browsing articles on CSS Tricks and came across Reading Position Indicator by Pankaj Parashar. I've seen this type of indicator in articles, blogs, and in lengthy terms and conditions that I've definitely read through thoroughly. I wanted to try recreating a reading position indicator using webforJ, and see if I could build it in less than 100 lines of code.

The webforJ 25.x cycle covered a lot of ground: new components, a fresh design language, smarter AI tooling, and plenty of polish, and it all wrapped up with the 26.00 release. Rather than a long recap, here's a short video that walks through the highlights.

In my time working with documentation and coding for customers I have built quite the number of demo apps myself, so by now I know what the shortcuts look like. The dataset is always small, with authentication and advanced features "coming soon" or hardcoded in instead of properly implemented. Filtering works fast, because coincidentally there are only five rows to filter. All of that isn't to say those demos are bad, after all they serve their purpose, but I wanted to see how efficiently I could build a demo that doesn't cut corners while still being small and easy to understand.

The webforJ Bookstore is my attempt at that. It's a book inventory manager built on webforJ and Spring Boot with live table filtering, colored genre chips, a data-bound edit drawer, and Spring Security handling who can do what. This post covers the pieces I found most worth writing about.

webforJ 26.00 is here, our first major version since the 25.x series kicked off, and a big one. It brings a top-to-bottom design system refresh, new tricks for the Dialog and TabbedPane components, and a clean break from deprecated APIs, all paired with automated tooling that does most of the upgrade work for you. The highlights are below, and as always the GitHub release overview has the complete picture.

There's something about native mobile apps that's hard to copy on the web: things move. Tap a photo and it expands. Go back and it shrinks to where it came from. The browser's View Transition API has been closing that gap, and webforJ 25.11 brings it to Java with webforJ View Transitions.