webforJ Release Cycle: How Often It Ships and How Upgrades Work
An app you build today will still be running when the people who started it have moved on to other projects. So before you pick a framework for it, you want to know how the framework itself behaves over time: how often new versions land, what an upgrade costs you, and how quickly a security problem gets fixed.
The webforJ release cycle is regular and written down. A major version arrives once a year, minor versions arrive every few weeks, patches ship when needed, and snapshot builds let you test a version before it is released. The sections below answer each question directly and link to the pages that back it up.
Moving a desktop Java app to the web?
Send us a screenshot of one screen and we'll reply with how it moves to webforJ.
How often does webforJ release?
webforJ ships a major version once a year, minor versions roughly every six to eight weeks, and patch releases when needed. That is the release model on our upgrading overview. These are the recent majors and minors.
| Release | Type | Date |
|---|---|---|
| 24.00 | Major | April 8, 2024 |
| 25.00 | Major | April 22, 2025 |
| 25.12 | Minor | March 17, 2026 |
| 26.00 | Major | April 28, 2026 |
| 26.01 | Minor | June 30, 2026 |
| 26.02 | Minor | August 31, 2026 |
Each of those versions has a release article: 24.00, 25.00, 25.12, 26.00, 26.01 and 26.02. Every release also comes with detailed release notes on GitHub that list new features, bug fixes and any action you need to take.
The version number sets your expectations. A number such as 26.01 is a minor release with incremental improvements, optimizations, and smaller features. A number such as 26.00 is a major release that can require configuration changes or changes to your code.
What do the release types mean?
The overview describes three kinds of release:
- Major releases happen annually. They bring significant new features and improvements and may need changes to existing apps.
- Minor releases happen several times a year. They bring incremental improvements, optimizations, and smaller features.
- Patch releases are released if needed. They address critical bugs, performance issues and security vulnerabilities, and carry an extra number such as 20.01.1.
We work to maintain compatibility, but major releases may include changes that require adjustments to apps, so the release notes list deprecated features for you to review.
How do webforJ upgrades work?
You read the upgrade guide for your target major version, then let an automated recipe do most of the edits. Major releases have upgrade guides in the upgrading section, and each one lists the changes existing apps need.
The 25.00 guide covers the move to Jetty 12 and the Jakarta EE10 servlet architecture. The 26.00 guide covers the move to Java 21 or Java 25, the move to Spring Boot 4.x, and the removed or replaced Table and Repository methods, each with a table of the old call next to the new one.
Design changes get their own treatment. The 26.00 design system guide calls the update incremental rather than a full rewrite: most v25 CSS variables remain available, the public API of the theme engine is preserved, and existing customizations continue to work without changes.
Can upgrades be automated?
Yes. webforJ ships OpenRewrite recipes in the webforj-rewrite artifact. The automated upgrades guide describes the flow. You add the OpenRewrite Maven plugin to your pom.xml with webforj-rewrite as a dependency, choose the recipe for your target version, and preview the result first:
mvn rewrite:dryRun
That command writes a diff to target/rewrite/rewrite.patch without touching any file. When the diff looks right, apply it:
mvn rewrite:run
The recipe updates dependencies, renames methods, changes types, and adjusts return types. Where no one-to-one replacement exists, it leaves a TODO comment in your code with specific instructions, so you can search your project for TODO to see what is left. Then you remove the plugin from your pom.xml.
Recipes exist for standard webforJ projects and for Spring Boot projects. You can also run them between majors to move away from newly deprecated APIs before they are removed in a later version.
If you work with an AI coding assistant, the webforj-upgrading-versions skill in the AI plugin runs the recipe for the target version and resolves the TODO comments with you. For targets with no published recipe, such as 24 to 25, it walks you through the manual route in the 25.00 guide.
How are security fixes delivered?
Critical security vulnerabilities are addressed in patch releases as soon as possible. Security is a priority in our release model. Patch releases address critical bugs, performance issues and security vulnerabilities, and carry an additional number such as 20.01.1.
Can I test a release before it ships?
Yes. Snapshot builds are available before most releases, and we encourage you to test against them so problems surface early. The snapshots guide shows how to find the newest snapshot version in the webforJ project on GitHub, set it as the webforj.version property in your POM, and add the Central Portal Snapshots repository so Maven can resolve it.
For a new project, startforJ offers the webforJ version that ends with (pre). Snapshots are under active development and subject to change, so keep them out of live production apps and use them on a branch or a test environment.
Is webforJ right for a long-lived app?
webforJ gives you a documented release model to plan a long-lived app around: a yearly major, minors every six to eight weeks, and patches for security. Upgrades come with a written guide per major version, an automated recipe that does most of the edits, a dry run that shows the diff first, and snapshots that let you try the next version early.
For the wider picture, read our guide to the full-stack Java framework.
FAQ
How often does webforJ release a new version?
A major version once a year, minor versions roughly every six to eight weeks, and patch versions when needed.
What does a patch release change?
It addresses critical bugs, performance issues and security vulnerabilities, with a number such as 20.01.1.
Do I have to upgrade by hand?
No. The webforj-rewrite OpenRewrite recipes handle most of the upgrade and leave TODO comments for the rest.
Where do I find what changed in a version?
In the GitHub release notes, the release article for that version, and the upgrade guide for major versions.
Plan your next webforJ upgrade
Open your pom.xml, note your webforj.version, and read the upgrading overview. Then run mvn rewrite:dryRun with the recipe for your target version and look at the diff before you change a single file.
正在用 webforJ 构建项目？
与团队聊聊您的项目、迁移事宜，或 webforJ 是否适合您。
继续阅读
Strangler Fig Pattern for a Java Swing App, Step by StepApply the strangler fig pattern to a Java Swing app. Run it in the browser with Webswing, embed it in webforJ, and replace screens one at a time.
Apache Tapestry alternative: a decision guide for Java teamsLooking for an Apache Tapestry alternative? See what carries over, what changes, and when to stay, then move one screen at a time to webforJ.
Is Java good for web development? Myths and factsIs Java good for web development? Four common beliefs about Java on the web, checked one by one, plus the cases where JavaScript is still the better pick.