A developer asks: "How do I control which users see which views?" In a webforJ app, the first instinct might be to call setVisible(false) on a navigation component based on the current user's role, or to conditionally add layout elements depending on permissions. It's direct and it works for what it does — but what it does is different from what the question was asking.

Controlling visibility and restricting access are different operations. Treating them as equivalent is how unintended access surfaces in production.

A product owner requests a feature: search-as-you-type across the customer list. The backend is an afternoon. Add a Spring service, write the query, wire up the result. Done. Then the wiring to the frontend starts: add a REST endpoint, configure CORS, set up Axios in the React component, handle the loading state, handle error responses, connect the frontend build pipeline to the backend. The feature took an afternoon. The protocol between the feature and the user took another two days.

That overhead isn't part of the feature. It's the cost of a protocol boundary between two systems written in different languages.

Broken access control has sat at the top of the OWASP Top 10 since 2021, and the 2025 list keeps it there. One of OWASP's own example scenarios is an app that keeps all its access control in the front end, where the attacker can't click through to the admin page because the JavaScript won't let them, so they skip the browser and request the URL with curl instead.

Here's a version of that you've probably written:

if (isAdmin) {
    Button delete = new Button("Delete user");
    delete.onClick(e -> userService.delete(selected));
    self.add(delete);
}

Ordinary users don't see the button. That feels like enough, and in a server-driven framework it feels like more than enough, because the business logic is all sitting safely in Java. This post is about what actually protects that handler, what webforJ gives you for free, and where the line between the two falls.

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 customers.jsp has been in production since 2011. The team knows every quirk — the pageContext.getAttribute calls that pull in the session-managed customer list, the JSTL loop that renders the rows, the shared header partial included from /WEB-INF/includes/header.jsp. It works. Operations knows how to deploy a WAR. The business rules are encoded in the tag libraries. On Monday, leadership asked for a modernization plan.

The SERP for "jsp modernization" gives you two answers: swap the template engine for Thymeleaf, or rebuild the frontend in React. Both are legitimate paths. Neither removes the template layer.

This post covers the third option: replace the JSP page with a Java component tree. Views become Java classes. The loop disappears from the source. The taglib becomes a plain Java class. The include becomes a constructor call. This is not a new idea — it is just underrepresented in the search results because most teams that have done it have not written it down.

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.