73 Beiträge markiert mit "Spring"

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.

Your users know what they want from a table. They just don't think in dropdowns and price fields. They think "laptops under 1000 that are in stock," and the filter form makes them translate that into five separate controls.

Natural language search for a Java table lets them type that sentence instead. The safe way to build it keeps the model away from your data: it only turns the sentence into a small typed filter, and plain Java applies that filter to the table. This post builds the flow with Spring AI and a webforJ Table.

When a security review lands on your desk, the first question is usually how much of the app an outsider can reach. A JavaScript front end plus a public REST API gives them a lot to work with. A secure Java web framework for enterprise use starts from the opposite end: keep state, business rules and access decisions on the server, and let the browser only render the interface.

webforJ, the full-stack Java framework, is built that way. Screens, routing, validation and access control are written in Java and run on the server, so you write no separate front-end codebase and no REST endpoints just to feed the UI.

Your operations console, case management tool or onboarding screen will run for ten years or more, handle sensitive records every day, and be maintained by people who have not been hired yet. The framework you pick today has to survive that, and so does the review it will go through.

If you are choosing a Java UI framework for banking and financial services, webforJ, the full-stack Java framework, is a strong candidate for internal and back-office apps. The business logic and the UI state stay on the server, the browser only renders components, routes are protected with Spring Security before a view exists, and your existing Java team and services carry straight over.

Java web app internationalization in webforJ takes three pieces: a messages.properties bundle per language, the t() method on your components, and a list of supported locales in your configuration. webforJ resolves keys with BundleTranslationResolver, can pick the user's language from the browser, and updates the UI at runtime when you call App.setLocale().

This guide walks through the whole path: bundles, translated components, locale detection, a language switcher, date and number formatting, and Spring Boot setup.

Somebody on the team asks the question before the first screen gets built: if we pick this UI framework and it stops fitting in four years, what do we have to throw away? It is a fair question, and a vague answer is worth nothing.

To avoid UI framework lock-in in Java, decide how much of the app is allowed to know about the framework. With webforJ the answer can be small. Business rules live in plain Java classes or Spring services, forms bind to plain beans validated with Jakarta Bean Validation, data comes through repositories, and only the view classes use webforJ components.

Most Java teams know the split: the backend is Java, and the screens live in a second project with another language, another build, and an API between the two. A Java full stack framework removes that split. It's a framework where you build every layer of a web app in Java: the screens, the routing between them, the forms and their validation, the security rules and the data access, all in one project with one build.

webforJ is the full-stack Java framework for business web apps: you build the whole app, screens included, in Java. On Spring Boot it ships as a single executable JAR, and your views receive services and repositories through constructor injection like any other Spring bean. The separate frontend project, the API contract and the validation you write twice all go away.

This post lists what a full stack Java app contains in webforJ, then walks through a small slice from entity to table to form.

Building a tool for an AI app has an awkward test loop. You change the code, restart, open a chat, and phrase a request so the model decides to call your tool, then hope it passes the arguments you meant. When something looks wrong, you can't tell whether the bug is in your code or in the conversation.

You can test a Java MCP App without an AI host, and skip that loop entirely. A webforJ MCP App is a view that your app's MCP server exposes as a tool. Run the app locally, connect MCPJam to it over HTTP, and call the tool yourself from its Playground. The view renders exactly as a chat client would show it, with no model in between.

Many GWT teams want to keep writing their UI in Java but no longer want a Java-to-JavaScript compile step in the middle. For a GWT to Spring Boot migration, webforJ is a full-stack Java framework and a GWT alternative built for that. You build screens from Java components, they run on the server next to your Spring Boot services, and the browser renders them. There is no client-side code to compile and no RPC layer between the UI and your services.

This post compares the two models, maps GWT concepts to their webforJ counterparts, and shows how a team can move an existing GWT app one screen at a time.

You have a domain model, a deadline, and a business app to deliver. Someone suggests a tool that turns your entities into working screens, and someone else asks what happens when the first customer wants a screen that looks different from the rest.

If you are searching for an OpenXava alternative, webforJ, the full-stack Java framework, is the choice when you want to write your screens yourself. You build views as Java classes with full control of layout, components, routing and validation, and an AI coding agent with the webforJ AI plugin writes them quickly and correctly. That removes the main reason to accept generated screens.

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.