A combo box in Java lets users pick an option from a list or type a value of their own. In webforJ, the ComboBox component handles both in one control, and you build it entirely in Java. This guide builds a country picker step by step. You will add preset items, set a placeholder, cap the dropdown height, turn custom input off for a field that needs a fixed answer, and read what the user chose.

You want an app that feels like a single page app: no white flash between screens, a working back button, links people can bookmark. You also want to keep your team in Java instead of adding a second codebase in JavaScript. A Java single page app framework has to cover three things: load the page once, change views in the browser without a reload, and keep the URL honest. webforJ does all three. Every webforJ app is a single page app, and the routes, parameters and navigation are written in Java.

Maybe you've heard it in a meeting already: the app feels outdated, users want it in a browser and on their phones, and every upgrade feels slow and risky. If you need to move a Java app to the web and mobile, the answer in this webinar is to stay in Java. You run the existing app in the browser first, then rebuild it one piece at a time with webforJ, the full-stack Java framework, while the business logic keeps working.

You write Java for a living, and the next project needs a browser interface. Every guide you open tells you to learn a second language first, plus a package manager, a bundler and a framework that changes every few years. It is fair to ask whether you really need all of that.

You don't. You can build a web app in Java without JavaScript, and with webforJ you do it by writing components, event handlers and routes as plain Java classes. The browser still runs JavaScript, but webforJ ships it and talks to it for you, so none of it lands in your source tree.

Recently, I was browsing articles on CSS Tricks and came across Reading Position Indicator by Pankaj Parashar. I've seen this type of indicator in articles, blogs, and in lengthy terms and conditions that I've definitely read through thoroughly. I wanted to try recreating a reading position indicator using webforJ, and see if I could build it in less than 100 lines of code.

Your users want an app with its own icon, and your team wants one codebase it can update in a single deploy. Those wishes usually set off the web app vs native app debate.

For a business app, you can have both. Build a web app in Java with webforJ, deploy it once to a server, and let users install it from the browser to their desktop or home screen.

Phone numbers arrive as 5551234567, 555-123-4567 and (555) 123 4567. Prices come in with stray letters, and dates show up in three different orders. Every form that accepts free text ends up cleaning it afterwards.

An input mask in Java stops that at the source. The field only accepts characters that fit the pattern and formats the value as the user types. In webforJ the masks are built in, so a clean phone, price or date field is a few lines of Java.

You know some Java, you have written console programs or a few classes, and now you want to see something running in a browser. Most guides at this point throw HTML, JavaScript, a template engine and a build pipeline at you before the first page shows up.

This java web app tutorial for beginners takes a shorter path. With webforJ, a full-stack Java framework, you build the page in Java, generate a working project in a minute and run it with one Maven command. By the end you will have a first Java web app on screen, a button that reacts to clicks, and a clear idea of where to go next.

Your feed has thousands of rows, and a page of numbered buttons feels dated. Users expect to keep scrolling and see more appear, without waiting for the whole list to load up front.

Infinite scroll in Java gives you exactly that: the list loads the next batch of items when the user reaches the bottom. In webforJ a single component handles the scroll detection, and everything else stays in your Java listener. The code in this guide is all Java.

Your team has a JSF app with a rich component library on top. The data tables, dialogs and forms all work, but every screen means an XHTML file, a managed bean and a set of update attributes that decide which part of the page refreshes. Adding a screen feels heavier than it should, and nobody on the team wants to change the view layer more than necessary.

If you are searching for a PrimeFaces alternative that keeps the rich component idea and drops the XHTML, webforJ, the full-stack Java framework, is our answer. You build every screen as plain Java classes with a ready set of components (Table, Dialog, Drawer, form fields with data binding), route to them with an annotation, and plug the result into Spring Boot when you have it.

Java web app security best practices start with one choice: keep the interface logic on the server. webforJ does exactly that. Your views run in Java, the browser only renders them, and whole classes of attack never get a foothold. What remains is a short list of habits: gate every route, treat input as untrusted, cap uploads and requests, keep secrets out of the repo, and run over HTTPS. This post covers each one for a webforJ app.

The webforJ 25.x cycle covered a lot of ground: new components, a fresh design language, smarter AI tooling, and plenty of polish, and it all wrapped up with the 26.00 release. Rather than a long recap, here's a short video that walks through the highlights.