What's new in version 26.03?

webforJ 26.03 is live! The headline is the automation layer, which lets an AI agent use a webforJ app the way a person does: it reads the page, finds what it needs, and acts, with exactly the permissions of the user it works for. The same layer powers TestBed, new browserless testing built for the way AI coding assistants work. Alongside them, craftforJ picks up component deletion and system-wide undo and redo, BBjShip brings webforJ deployment to BBjServices for BBj developers, an updated DWC Design Kit brings Design System 2.0 to Figma, and important security fixes make this an upgrade we recommend for every app. See the highlights below, and as always, the GitHub release overview has the complete picture.

AI agents that use your app

Software has always had one kind of user: a person in front of a screen. That's changing. AI agents are starting to work inside the same apps people do, filling in forms, filtering lists, and clicking through the steps of a task on someone's behalf. 26.03 makes webforJ ready for that user, with an automation layer that gives an agent the same app a person gets, and nothing more.

In the video, an agent works through a task in the running app while the user watches: it clicks buttons, filters tables, and moves through the UI the same way the user would, and every step happens on screen. The agent plans the task in steps, and when several actions fit together, such as filling in a whole form, it takes them as one batch instead of returning to the model after each click.

The automation layer gives an agent three abilities:

• See. A snapshot describes the page as plain text, one line per component, with what each one shows. An agent reads that the way it reads any text, so it reads exactly what's on the user's screen without a screenshot.
• Find. ComponentLocator picks a component out the way a person does, by its type and what it shows, such as a field by its label or a button by its text.
• Act. UserInteraction makes the gestures of a user: clicking, typing, choosing, sorting a table, expanding a tree.

String page = Snapshot.render(view);

var export = ComponentLocator.of(Button.class).byText("Export").locate();
UserInteraction.click(export);

What an agent can't do matters as much as what it can. The automation layer acts through the UI, so it's bound by the same rules as the user it works for. It only makes gestures a user could make: a disabled button stays disabled, and clicking it fails instead of running its listener. Its view of the page is the user's view, and it can't reach anything the user's permissions keep them from. There's no back door to secure separately, because the agent uses the same door as everyone else.

As a developer, you set up the agent loop: the model, the prompt, and when the agent runs. The automation layer supplies the tools. It's the same arrangement a coding assistant has with your project, where the assistant reasons and its read and write tools do the work. Here the tools are see, find, and act, and the project is your running app.

The same API powers TestBed, and it doesn't care where it runs. In a unit test it drives a view headless inside the JVM; in the browser it drives the live app in front of the user. Code that tests a view and an agent that uses it speak the same language, so everything you learn writing tests carries straight over to building agents, and the other way around.

Learn More

• Finding components and User interaction cover ComponentLocator and UserInteraction in detail.
• The webforj-automation reference lists every locator and every interaction, one package per component.

Browserless testing with TestBed

AI coding assistants now write a growing share of the code in Java apps, and what keeps that code honest is how fast the assistant can check its own work. TestBed is webforJ's new browserless testing, and it gives assistants that check. A view runs inside a plain JUnit test. No browser is opened and no server is started, so a test finishes inside the JVM and an agent gets a pass or a fail right after every change it makes.

Snapshots give the assistant context. A single matchesSnapshot() check writes down everything a user would see in a view, one line per component, as plain text stored next to the test. A model reads that file the way it reads code: it gets the exact content of the view without a browser or a screenshot, and when a change breaks something, the failure is a text diff of what moved.

verifyThat(summary).matchesSnapshot();

OrderSummaryTest.shouldMatchTheSnapshot.yml

# webforJ testbed snapshot v1
- OrderSummary [composite=Div] [node=div]:
  - Paragraph "Order 1042" [composite=Element] [node=p]
  - TextField [label=Note] [placeholder="Delivery instructions"]
  - Paragraph "Discount applied" [composite=Element] [node=p] [hidden]
  - Button "Pay" [theme=primary]:
    - Icon [slot=prefix] [name=credit-card] [composite=Element] [node=dwc-icon]
  - Button "Cancel" [disabled]

The webforJ MCP server is backed by the TestBed documentation and API reference, so an assistant writes tests against the real API instead of guessing at it.

The same tests work just as well for the developers reviewing that code. A test reads like the steps a user would take:

@Test
void shouldSubscribeTheEmailTheUserTyped(WebforjTestbed context) {
  context.add(new NewsletterForm());

  var email = ComponentLocator.of(TextField.class).byLabel("Email").locate();
  var subscribe = ComponentLocator.of(Button.class).byText("Subscribe").locate();

  email.setValue("hello@example.com");
  subscribe.click();

  var status = ComponentLocator.of(Paragraph.class).locate();
  assertThat(status.getText()).isEqualTo("Subscribed hello@example.com");
}

Components attach, fire their events, and navigate exactly as they do in a running app, and every interaction finishes before the next line of the test runs, so nothing waits and nothing flakes. Browser-dependent tests still have their place for what only a browser shows, but TestBed is where the fast feedback lives.

Resources

• TestBed documentation: setup, locators, user interactions, assertions, and snapshots.
• TestBed unit tests for the documentation demos: every demo in the webforJ documentation is covered by TestBed tests, a working reference you can browse.

craftforJ: delete components, undo and redo

craftforJ landed in 26.02 and let you select a component in your running app, change its properties, and write the result back to your Java source. 26.03 extends that same pattern to deleting components, and makes every change craftforJ makes reversible.

Select a component in the inspector and delete it. craftforJ removes the component from the Java file that created it, so the source stays in step with the running app. Trees of components work the same way as individual ones, so removing a wrapping layout drops the layout and the children it held in one action.

Every one of those actions can now be undone and redone, including the ones the AI assistant takes on your behalf. Change a button's theme by hand, apply a round of agent edits, delete a layout: every step is reversible, and the undo reaches back into the Java file too. The source and the running app move together, forward or backward, so a change you want to walk back is one keystroke rather than a careful hand-edit of the file the tool wrote.

The practical effect is that experimenting in craftforJ is cheap. Try an edit, run it, undo it if you don't like what you see, redo it if you change your mind. The commit to source is still yours when you want it, and now the commit back out is too.

Learn More

See the craftforJ documentation for the inspector, source changes, and the assistant.

BBjShip

BBjShip brings the webforJ development experience to BBj developers. With BBjShip, mvn runs your app straight from the project in the BBjServices of your own machine, with the same dev tools every other webforJ app gets:

• Live reload: changes you compile reach the running app without a redeploy, and the open pages update on their own.
• Hotswap: HotswapAgent swaps changed classes into the running BBjServices, set up for you on the first run.
• craftforJ: select a component in the running app, change it, delete it, or ask the AI assistant, and the change lands in your Java source.

Starting a new project takes one choice. In startforJ, set Runs on to BBjServices, and the generated project runs with BBjServices from the start. From the command line, the hello-world, blank, tabs, and sidemenu archetypes do the same with -Dflavor=webforj-bbj:

mvn -B archetype:generate \
  -DarchetypeGroupId=com.webforj \
  -DarchetypeArtifactId=webforj-archetype-hello-world \
  -DarchetypeVersion=LATEST \
  -DgroupId=org.example \
  -DartifactId=my-app \
  -Dversion=1.0-SNAPSHOT \
  -Dflavor=webforj-bbj

When the app is ready, the same build plugin deploys it, either from the BBj machine or from another machine such as a CI server, and the app runs in BBjServices like any other app you manage in Enterprise Manager.

BBjShip also comes with its own bbjship command line for BBj administrators. On the BBj machine, it lists the deployed apps, deploys or undeploys an app, turns the deployment endpoint and development runs on or off, and resets everything BBjShip set up:

bbjship apps list
bbjship apps undeploy my-app

The webforJ install plugin is deprecated

BBjShip replaces the webforJ install plugin. As of 26.03 the install plugin is deprecated, and a future release removes it. If your project deploys with the install plugin today, move it to BBjShip: a single OpenRewrite run updates the pom.xml and webforj.conf, and your Java code stays unchanged. See Existing projects for the steps.

Learn More

See the BBjShip documentation for installation, getting started, deployment, existing-project setup, command-line reference, and troubleshooting.

DWC Design Kit for Figma

The DWC Design Kit, the official Figma resource for designing webforJ apps, has a new version built for Design System 2.0, the visual refresh that arrived in 26.00. It covers every DWC component as it looks in webforJ 26 and later, with its themes, expanses, and states, along with the updated color palettes, typography, spacing, and shadow tokens, set up as Figma variables and styles in both light and dark mode.

Designers and developers work from the same source: a screen designed with the kit uses the components and tokens the app renders, so the step from mockup to Java code doesn't involve translating one visual language into another.

Learn More

See the styling overview for the kit, or open the DWC Design Kit on Figma Community.

Security updates

26.03 includes important security fixes across the framework, among them improvements to authentication and authorization in the Spring Security integration. We strongly recommend that every app upgrade to 26.03. The fixes apply as soon as you update the version, with no change to your code.

Nothing breaks on upgrade. If you're on 26.x already, the upgrade is a version bump; if you're on 25.x, see the automated migration guide for the OpenRewrite recipes that take care of most of the work.

Thanks to our new contributors

A big thank you to @AzazelSensei and @builtbyjuls, who made their first contributions to webforJ in this release! If you've been considering a contribution of your own, the webforJ repository is open, and we read every pull request that comes in.

---

That's 26.03 in a nutshell! For the complete changelog, see the GitHub release.