一条帖子 个标签为 "Web Development"

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.

To add dark mode in a Java web app with webforJ, put @AppTheme("system") on your App class and register a light and a dark theme with @AppLightTheme and @AppDarkTheme. The app then follows the operating system setting. To let users choose for themselves, call App.setTheme() from a control in your header and save the answer with LocalStorage.

webforJ ships a light and a dark theme, so every component already has a dark variant. The only work left for you is your own CSS. This post covers the setup, the switch, the saved choice and how to write custom styles that hold up in both modes.

If you want to keep writing Java and you are picking a Java GUI framework today, webforJ is the option that gets you a browser-delivered UI without leaving the language. You build screens from Java classes, run them on the server, and users open a URL. Swing and JavaFX remain the choice when the app must work offline. If offline isn't a requirement, a webforJ app can be installed too, so it sits on the desktop, home screen or app menu like a native app.

The decision is mostly about delivery. Swing and JavaFX put the UI on each user's machine. A web UI written in Java puts it on one server and shows it in a browser. This post compares the three on the questions that change the outcome, then shows what the same button handler looks like in Swing and in webforJ.

You are about to commit a team to a framework for a business app, and before the first screen exists you want to know whether the parts you need are already there. A data table, date entry, dialogs, a navigation shell, a chart. Gaps show up late, so ask early.

This is the list. The webforJ components cover the screens a business app is made of, and you use them from Java, in the same project as your services and models. Below is what ships, how it is grouped, and what to do for the rare case where you want something more.

A multi-select Java UI in webforJ is a ListBox with its selection mode set to MULTIPLE. The user holds Shift, Control or Command to pick several items, and your Java code reads the chosen values with getSelectedKeys(). When the user should pick exactly one value from a fixed set, a ChoiceBox is the better fit. In this guide you build both, read and set the selection from Java, and learn when each component is the right one.

Your Spring Boot app started with a few server-rendered pages and it worked well. Then the requests changed. A table that sorts and pages, a dialog that edits a row, a form that validates as you type. Each one adds a template, a fragment endpoint or a script file, and the screens start to feel heavier than the app behind them.

If that sounds familiar, you are probably searching for a Thymeleaf alternative for Spring Boot. The short answer is webforJ, the full-stack Java framework. You keep Spring Boot, your beans and your repositories, and you build the screens as Java components that hold their state on the server. There are no template files, no fragment endpoints and no hand-written JavaScript for interactivity.

If you want a Kotlin web framework that builds the whole UI in Kotlin, webforJ has one. Add the webforj-kotlin module and the Kotlin Maven plugin to a webforJ project, and you build web UIs with a type-safe Kotlin DSL: flexLayout { button("Save") { onClick { save() } } }. There is no HTML template and no JavaScript.

The DSL has been available since webforJ 25.12. It covers the standard components, nests like the UI it describes, mixes with Java classes in the same project, and works with Spring Boot. This post shows how to build a web app in Kotlin with it, from setup to your own DSL functions.

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.

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.

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.