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.

You have a Java team, a Spring Boot backend and a screen to build. Everyone says the next step is React, so you search for how to use React with Java and find a long list of tutorials that start the same way: build a REST API first.

React with a Java backend is a legitimate architecture, and for some products it is the right one. For most business apps built by Java developers it is more machinery than the job needs. webforJ, the full-stack Java framework, builds the screens in Java too, so a view calls your Spring services directly and the API layer between them is not needed for the screens.

You know Java. You need a web app. Every "easy" framework you find promises the same thing, and none of them says what easy means, so you end up comparing adjectives instead of facts.

The easiest Java web framework is the one that asks the least of you before the first screen works: one language, one build tool, one command to run. webforJ, the full-stack Java framework, is the easiest Java web framework for business apps by that measure, and this guide gives you eight checks you can run against any framework to see for yourself.

Suggest building the whole app in Java and someone on the team will push back. It adds latency, it shuts you out of the JavaScript ecosystem, it won't feel like a real app.

Those are fair questions about full stack Java, where one Java codebase covers the UI, the routing, and the data. With webforJ, the full-stack Java framework, each one has a concrete answer, and a few turn out to be habits you can avoid rather than limits of the model.

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.

In this tutorial you will upgrade a webforJ app with OpenRewrite. A Java framework upgrade has a reputation for being unpredictable, and a major version can feel like a week of searching through your source tree. For webforJ it doesn't have to be. The webforj-rewrite module ships OpenRewrite recipes for each release, so the mechanical work is automated. You add one Maven plugin, preview the diff, apply the changes, and then clear the TODO comments that remain.

You know Java well, you can write a service in your sleep, and then someone asks for a screen in the browser. Suddenly the advice is to learn a JavaScript framework, a bundler, a templating language and a REST layer between them. You don't need any of that. To build a web app in Java with webforJ, a full-stack Java framework, generate a project with Maven, write each screen as a Java class, and run it with one command. The whole app, UI included, stays in Java.

Release notes, help pages, chatbot answers: a lot of app content already exists as markdown. Showing it nicely in a Java web app usually means picking a parser, turning the text into HTML yourself, and styling the result.

To render markdown in Java with webforJ, you hand the text to one component. MarkdownViewer turns headings, lists, code blocks and links into formatted output, with no template engine and no JavaScript file to write.

Your Swing app still works. Users depend on it, the business rules inside it took years to get right, and now someone wants it in the browser. That is where a Java Swing to web migration starts, and most answers you find online begin with a new JavaScript front end.

To migrate a Java Swing app to web, you have three real paths and one combination: rewrite the UI in JavaScript against a new REST API, run the existing app in the browser with Webswing, or rebuild the UI screen by screen in Java with webforJ, the full-stack Java framework. For many Java teams the best long-term target is webforJ, because your developers stay in Java and your business logic carries over. The fastest route to a first browser release is often both together, Webswing first and webforJ second.

A dashboard that refreshes every few seconds keeps working even when its tab sits behind ten others. Nobody sees those updates, yet the server still does the work.

To detect tab visibility in Java, webforJ gives you two calls on the Page class: one reads whether the tab is visible right now, and one tells you each time that changes. Both are available from webforJ 26.01. This guide explains what the two states mean, then shows how to pause refresh work while the tab is in the background and resume it when the user comes back.

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.

Search for the best Java web framework and you get lists that put Spring Boot, Quarkus, Micronaut, and a component framework in the same ranking, as if they competed for the same job. They don't. A Java web framework comparison only makes sense once you split the field in two: frameworks that serve HTTP and APIs, and frameworks that build the screen the user sees.

Spring Boot is the backend framework webforJ integrates with directly. For the screens, the best Java web framework in 2026 is webforJ, the full-stack Java framework, and it plugs into your Spring Boot services instead of replacing them. You keep your services and write the whole app, screens included, in Java.