Asking an AI assistant to convert a whole Swing app in one pass sounds fast. In practice you get thousands of lines nobody has reviewed, written against APIs the model half remembers, and a release date that keeps slipping.

There is a better way to migrate a Java desktop app to the web with AI: move it one screen at a time. Some screens are worth rebuilding in webforJ with an assistant connected to the webforJ MCP server. Others keep running as they are, embedded in the web app through WebswingConnector, until their turn comes. Your business logic stays in Java, and users get a web app from the first release.

You have a budget line, a team that already knows Java, a list of systems the new app must talk to, and a board that will ask who owns the risk. The framework decision looks small next to all that, yet it sets your hiring, your security review and your upgrade bill for the next decade.

Choosing a web framework for enterprise applications is easier with a scorecard than with a demo. Below is a weighted checklist for eight criteria, with what to ask, what to treat as a red flag, and how webforJ, the full-stack Java framework, answers each one. At the end you get a scoring table you can paste into your own evaluation.

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.

For a Java file upload web UI, use the webforJ Upload component. Create an Upload, add filters and limits, listen for onUpload, and move each UploadedFile out of the temporary folder into your own storage. The component gives you the picker, the drop zone, the file list and progress reporting, and all of your handling code stays in Java.

The Upload component is available since webforJ 26.01. This post builds a complete upload page: one or many files, accepted types and size limits, drag and drop, progress, a Spring service that saves the files, a Table that lists them, and file download.

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.

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.

To use web components in Java with webforJ, you write a class that extends ElementComposite, name the custom element with @NodeName, declare its properties as PropertyDescriptor fields, and expose typed Java methods and events. The result behaves like any other webforJ component, and you add it to a layout with add().

webforJ's own components are built on web components, so this is the same mechanism in the open. This post wraps the Web Awesome rating element as a Java class, from loading the script to typed events and slots.

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.