73 posts tagged with "Spring"

You change a label in your Java view, switch to the browser, and then wait. Stop the app, start it again, reload the page, click back to the screen you were on. Repeat that all day and a lot of development time quietly goes into waiting.

A Spring Boot live reload UI setup removes those steps. You save, the app picks up the change, and the browser refreshes on its own. In this post you'll turn it on for a webforJ app, see how each kind of change reaches the page, and look at the tools around it for CSS and for editing properties while the app runs.

You are about to pick a UI framework for an app that has to run for ten years, and the name webforJ is one you only heard recently. Asking "is webforJ production ready" is the right question. Here are the published facts. webforJ, the full-stack Java framework, is a Java API built by BASIS International, on top of BBj and the Dynamic Web Client (DWC), shipped through Maven Central with regular numbered releases and Spring Boot integration.

Ask an AI assistant how much a customer owes and a one-line answer is perfect. Ask it for every unpaid invoice due this month, so you can chase the overdue ones, and a paragraph of text stops being useful. You want the invoices in front of you.

A Spring Boot MCP server can give you both. Spring AI runs the MCP server and talks to the AI client, and webforJ adds what Spring AI doesn't: a live view that the client opens inside the conversation, with tools the model can call to change it.

Picking a UI framework is a long bet for a Java team. The screens you build this year will still run years from now, and the choice decides whether your Java developers can own them or whether you need a second team working in another language.

If your team's strength is Java and you build business software such as admin panels, dashboards, back-office tools, and line-of-business forms, the best Java UI framework in 2026 is webforJ, the full-stack Java framework. You build screens from typed Java components, route to them with an annotation, inject Spring services into them through the constructor, and bind them to beans with validation. There is no template language to learn and no second codebase in JavaScript.

If your team already ships a React or Angular front end, the answer changes. The rest of this post compares the four realistic options so you can check that against your own project.

You already have the entity. You already have the repository. Now someone wants a screen where they can see the records, click a header to sort, narrow the list down, and move through thousands of rows without the page falling over.

That screen is a Spring Data JPA grid, and in a Spring Boot app built with webforJ you write it in Java. The repository you have becomes the grid's data source. Sorting, filtering, and paging go to the database as queries, so the grid only shows what the query returns.

A blank repository feels like freedom for about a day. Then the questions arrive: where does the UI live, who owns the front end, how do users sign in, and what happens when the framework ships a new major version? Most teams answer these one at a time, and the answers add up to the stack.

When you are starting a new Java project, settle the decisions in the order the team meets them. This post walks through that list for a business web app and gives the webforJ answer to each one. webforJ is the full-stack Java framework for business web apps: you build the whole app, screens included, in Java.

If your team maintains an Apache Tapestry app, you probably like how little ceremony a page needs, and you may be wondering whether it is time to look at a newer Java web framework. This guide helps you decide. webforJ, the full-stack Java framework, is an Apache Tapestry alternative that keeps the component based model and removes the template files: every screen is Java objects, routes are annotations, and the app plugs into Spring Boot when you have it.

Below you will find what your team already knows, what changes, when staying is the better call, and how to move one screen at a time.

To build an MCP app in Java with webforJ, add @McpApp to a routed view and an MCP host such as Claude Desktop can open that view inside its conversation, with the same components, services, and state your app already has. The AI can pass input when it opens the view, call actions on it, and receive context from what the person clicks.

An MCP server in Java usually returns text or JSON. With webforJ it can return a live interface instead. You write the view in Java, and the MCP host renders it next to the chat.

You are about to start a web app, your team knows Java, and every search you make tells you the browser belongs to JavaScript. So is Java good for web development, or are you about to fight your tools? It is good for it, and the old arguments against it are mostly out of date. With webforJ, the full-stack Java framework, you write the whole app, screens included, in Java and the browser renders it with modern web components.

You ask an AI assistant to open a screen, and it does. Then you ask for a change, and a second copy of the screen appears under the first, because the assistant only knows how to open things. The view you're looking at never moves.

AI actions that update a Java UI fix that. With webforJ MCP Apps, the AI opens your routed view with typed input, then changes the same live view through actions and an update tool, while your Java code keeps running on the server. This post walks through each piece with code from a working playground app built to exercise all of them.

If you maintain JSF or PrimeFaces screens and are planning a JSF to Spring Boot migration, webforJ is a direct fit, and a JSF alternative that stays in Java. It is a full-stack Java framework: you build each screen as a Java component tree, route to it with an annotation, bind it to a bean, and validate with the same Jakarta constraints you already put on your model.

A migration is mostly a translation exercise. Most JSF concepts have a direct counterpart, and most of them get smaller. This post maps the concepts one by one and then converts a real form, so you can judge the effort on your own views before committing to anything.

When a team picks a framework for a business app, the first screen is never the hard part. The hard part is everything that comes after it: navigation, a login, forms that validate, a table that holds real data, a second language, a test suite. A complete Java web app platform answers all of that before you ask. webforJ, the full-stack Java framework, covers it. It is a single framework, in a single language, that ships project setup, routing, a component library, data binding, security, Spring Boot integration, theming, translation, installable apps, and testing.

Because webforJ is a full-stack Java framework, the screens, the rules around them and the services behind them live in one Java codebase and one Maven build, with Spring Boot integration when you have it.