Vaadin.com Blog

How South Tyrol modernized government software with Java and Vaadin

lilli@vaadin.com (Lilli Salo) — Fri, 29 May 2026 13:12:04 GMT

Südtiroler Gemeindenverband Genossenschaft replaced a legacy Delphi monolith with a modern cloud-native eGovernment platform built with Java, Kubernetes, and Vaadin. With a small in-house team, they delivered 16 production modules supporting municipalities across South Tyrol while preparing the platform for long-term public-sector reuse.

Supporting the digital infrastructure of 116 municipalities

Südtiroler Gemeindenverband Genossenschaft is the IT services consortium for South Tyrol’s local government and one of the few in-house organizations in Italy responsible for centralizing software development for an entire regional public administration.

Its platform, Goffice 2.0, supports:

116 municipalities
7 district communities
roughly 5,000 daily users

The project is delivered by a small in-house team consisting of:

4 Full stack Java developers: Simon Nogler, Walter Zöggeler, Domingo Sacristan, and Roberto Cappuccio
Business analyst: Sara Tumiati
Architect: Renzo Poli
Scrum Master: Edoardo Scepi
EU-funding project manager: Tarcisio Coianiz

Together, they build and maintain software used daily across a large public administration ecosystem.

Replacing a legacy Delphi monolith without disrupting public services

Every working day, civil servants across South Tyrol rely on Goffice to manage taxes, permits, invoicing, digital signatures, and other core government processes.

But the Delphi-based system behind the platform was becoming increasingly difficult to maintain and modernize. The old platform had become harder to evolve at a time when municipalities were under growing pressure to digitize public services and integrate with national eGovernment systems.

The application was built as a traditional client-server monolith with:

no responsive web interface
limited interoperability
growing maintenance complexity
difficult integration with modern public-sector infrastructure

Replacing it was unavoidable. The challenge was how to modernize critical government software without disrupting public services, while working within fixed public-sector budgets and a small in-house development team.

Instead of outsourcing the project, Südtiroler Gemeindenverband Genossenschaft rebuilt the platform themselves.

In five years, the team delivered 16 production modules on a modern cloud-native architecture using Java, Kubernetes, and Vaadin. The result is Goffice 2.0, an open-source eGovernment platform designed to support South Tyrol’s municipalities through at least 2030.

The Goffice 2.0 platform helps municipalities manage taxes, billing, and public services through a modern web interface built with Vaadin.

Building a modern eGovernment platform with a seven-person team

The modernization effort required more than rewriting software. The organization restructured from vertical silos into horizontal Scrum teams and hired a dedicated architect to guide the transition to full stack and cloud-native development.

Developers also received internal training to accelerate the move into the modern Java ecosystem without relying heavily on external consulting.

Migration happened incrementally. The team started with smaller, lower-risk modules first, building reusable patterns and confidence before tackling more complex systems.

One of the most important technical decisions was investing early in a shared framework layer for reusable forms, grids, views, authentication, and common UI components. That internal investment helped the team maintain consistency across modules while staying productive with a relatively small development organization.

Today, the platform includes 16 production modules running in a cloud-native environment across 116 public administrations.

Screenshot of the Goffice 2.0 invoicing module showing a multi-step invoice creation workflow with customer information, billing details, document metadata, and electronic transmission fields.

Why the team chose full stack Java and Vaadin

The team evaluated Angular during the planning phase but quickly realized the frontend complexity would be difficult to manage for such a small group working across a large and constantly evolving public-sector domain.

There was also a practical human challenge. Most developers had spent more than a decade working in Delphi, a component-based and event-driven development environment. At the same time, the organization was already transitioning to Kubernetes, microservices, cloud-native architecture, and modern DevOps workflows.

The team needed a UI framework that would not force a complete cognitive reset on top of an already demanding modernization effort.

Vaadin provided a development model that felt familiar enough to Delphi to keep developers productive while modernizing the rest of the stack. A nearby company that had already used Vaadin to modernize a comparable client-server application also helped validate the decision before the team committed.

At the same time, the project had strict European Regional Development Fund (ERDF) requirements. The platform needed to be:

cloud-native
modular
open source
interoperable with national systems
sustainable for long-term in-house maintenance

It also required integrations with key Italian public-sector infrastructure, including SPID, PagoPA, FatturaPA, and national digital identity services.

Modernizing one of the region’s most complex public-sector systems

The most technically demanding migration so far has been the tax module, which manages tax and fee processes for all 116 municipalities.

The system includes waste management, water services, electronic invoicing, SEPA integrations, PagoPA integrations, and national registry integrations, making it the team’s most complex Delphi-to-Vaadin migration to date.

Screenshot of the Goffice 2.0 client management module showing a form for creating and maintaining citizen records, including personal information, address details, contact information, and administrative data.

From legacy monolith to modern public platform

Today, Goffice 2.0 runs 16 production modules across 116 public administrations in a cloud-based environment with near-24/7 availability.

Michele Tais estimates that delivering the same scope using the previous Delphi stack would have taken up to 30% longer, which made a real difference for a small public-sector team operating under fixed budgets and EU funding timelines.

The platform has also supported seven successful NextGen EU funding applications, helping municipalities secure substantial public investment for digital modernization initiatives.

For the roughly 5,000 civil servants using the platform daily, the improvements are visible in everyday work. End-user feedback consistently describes the new system as:

Cleaner
More responsive
Easier to navigate
More modern than the previous platform

Goffice 2.0 has also been registered in Italy’s national software reuse catalogue (AGID), allowing other public administrations across the country to adopt the platform directly.

The Goffice 2.0 citizen portal gives residents secure access to contracts, documents, and property information, reducing administrative overhead for municipalities.

The Goffice 2.0 citizen portal enables residents to access municipal services and manage payments online.

Building public-sector software designed for reuse

The next major migration projects include building management and business licensing systems, planned over the next three to four years. The team continues to build new modules with Vaadin as part of its long-term platform strategy.

In 2027, Südtiroler Gemeindenverband Genossenschaft plans to publish the full Goffice 2.0 architecture and source code publicly, allowing municipalities across Italy to reuse and contribute to the platform.

Planning a public-sector modernization project?

Learn how Vaadin helps teams replace legacy systems with modern full-stack Java applications.

A more Playwright-like API for Vaadin browserless tests

matti@vaadin.com (Matti Tahvonen) — Thu, 28 May 2026 10:25:01 GMT

In Vaadin 25.1 the browserless-test module became part of the Apache 2 licensed open core framework. We believe it's on track to become a key part of the agentic-coding setup for Vaadin apps. In the upcoming Vaadin 25.2 we're bringing in API additions that make its usage more flexible and intuitive.

drops the mandatory test base class — your test class extends whatever your project conventions ask for (Spring, JUnit base of your own, nothing at all).
collapses query and interaction into one step — findButton() returns a ready-to-use type for testing instead of a raw component reference you have to wrap with test(...).
makes multi-user and multi-window first-class — the three-level context structure (app → user → ui) is the same surface a real Vaadin app has, so simulating two users sharing a session or one user opening two windows is just driving the UIs via two different handles.

The existing API continues to work; adoption of the new mode can happen iteratively. API can be tested using Vaadin 25.2.0-beta1. This post walks through what the new style API looks like and why we think this direction is worth committing to.

A short example

Here's a small test in the new shape — no class hierarchy, the try-with-resources owns the Vaadin environment for the test:

```java
@Test
void signIn_validCredentials_navigatesHome() {
 try (var app = BrowserlessApplicationContext.create("com.acme.myapp")) {
 var ui = app.newUser().newWindow();
 ui.navigate(LoginView.class);

 ui.findTextField().withLabel("Email").setValue("ada@example.com");
 ui.findTextField().withLabel("Password").setValue("hunter2");
 ui.findButton().withCaption("Sign in").click();

 Assertions.assertInstanceOf(HomeView.class, ui.getCurrentView());
 }
}
```

A few things to notice: no extends BrowserlessTest, no field-grabbing through a view reference, no test(component).setValue(...) wrapping step between the query and the interaction. The two key types that make this work are introduced next.

Contexts

A Browserless test now has a clear three-level structure that mirrors what a real Vaadin app has:

Concept	Type	What it represents
Application	`BrowserlessApplicationContext`	the Vaadin service + routes — shared across users. There are `SpringBrowserlessApplicationContext` and `QuarkusBrowserlessApplicationContext` factories to help working with the common dependency injection frameworks.
User	`BrowserlessUserContext`	one user session with their own security state
UI	`BrowserlessUIContext`	one open browser window for that user

A test reaches them through a straight three-step chain:

```java
try (var app = BrowserlessApplicationContext.create(routes)) {
 var ui = app.newUser().newWindow();
 ui.navigate(MyView.class);

 // test code uses `ui` to query and act
}
```

ui (a BrowserlessUIContext) is the surface tests interact with: it's where you call findButton(...), findTextField(...), navigate(...), fireShortcut(...). It's also where Vaadin's thread-locals are activated under the hood when you switch between two ui instances — so multi-user tests don't have to think about thread-local state at all.

Multi-user is just two windows

The three-level structure makes scenarios that previously required either manual session juggling or an actual browser become natural:

```java
try (var app = SpringBrowserlessApplicationContext.createSecured(routes, ctx)) {
 var alice = app.newUser("alice", "ADMIN").newWindow();
 var bob = app.newUser("bob", "USER").newWindow();

alice.navigate(AdminView.class); // OK — has the role

 // Navigating to admin view as regular user should through an exception
 Assertions.assertThrows(SecurityException.class,
 () -> bob.navigate(AdminView.class));

 // Interleave freely — calling any DSL method on `alice` or `bob`
 // re-activates that user's security context automatically.
 alice.findButton().withText("Add user").click();
 bob.findTextField().withLabel("Search users").setValue("alice");
}
```

The same pattern lets a single user open multiple windows:

```java
var alice = app.newUser();
var primary = alice.newWindow();
var secondary = alice.newWindow();
```

You can use this even when "multi-user" or "multi-window" isn't the point of the test — it just turns out to be the cleanest way to compose a fresh isolated environment per test method.

No mandated superclass

Notice what isn't in the snippets above: there's no extends BrowserlessTest, no @ViewPackages annotation requiring you to pre-list your views. The contexts handle their own lifecycle, so your test class can extend whatever your test conventions ask for (Spring's @SpringBootTest, your own base class, nothing at all) without fighting the test framework. The library's lifecycle assumptions stay inside the try-with-resources.

Locators

Once you have a ui, the locator API replaces the older two-step "find then wrap" pattern. The old shape looked like:

```java
// Old: query returns a Component, test() wraps it for interaction
TextField field = $(TextField.class).withLabel("Email").first();
test(field).setValue("a@b.com");
```

The new shape collapses that into one chain:

```java
// New: query returns a ready-to-use tester

TextFieldLocator emailFieldLocator = ui.findTextField().withLabel("Email");
emailFieldLocator.setValue("a@b.com");

// Or, equivalently, as a one-liner:
ui.findTextField().withLabel("Email").setValue("a@b.com");
```

findTextField() returns a TextFieldLocator, which is the test surface for TextField. No test() wrapping step. The tester methods that used to live on TextFieldTester are now method calls directly on the locator. Same for every other component: findButton(), findGrid(...), findCheckbox(), etc.

Similarly to Playwright, in case the locator is not specific, e.g. matches multiple components, it will throw a runtime exception in case a user interaction is simulated. You can specify the target component with additional rules or e.g. with the atIndex(int) method.

Components with parameterized testers (Grid, ComboBox, RadioButtonGroup) take a class witness once:

```java
Person first = ui.findGrid(Person.class).getRow(0);
ui.findComboBox(User.class).select(user);
```

Filter chain reads like a sentence

The filter methods on a locator compose into a focused find:

```java
ui.findButton().withText("Save").click();
ui.findButton().withAriaLabel("Reset form").click();
ui.findTextField().withLabel("Email").setValue("a@b.com");
ui.findButton().withClassName("primary").withTextContaining("Submit").click();
```

withLabel(...) is new in the locator API and worth a sentence: it resolves both the component's own label property and a separate <label for="..."> element (e.g. a NativeLabel you attached explicitly). That's the pattern you'd reach for in Playwright with getByLabel(...) — now it's first-class here too.

The escape hatch is one call away

Sometimes the tester surface doesn't cover what an assertion needs. component() gives you the underlying component instance:

```java
TextField email = ui.findTextField().withLabel("Email").component();
Assertions.assertEquals("a@b.com", email.getValue());
Assertions.assertTrue(email.isInvalid());
```

This is the steam-valve for things the tester abstraction doesn't expose. Most tests won't need it for interaction, but it's there for the assertion side. The locator stays the primary surface; the component is the fallback.

Why the wrap step matters

It would be tempting to say "well, you can interact directly with the Component API — why bother with testers at all?" The reason testers exist (and now locators) is that direct Component-level interaction doesn't simulate what the user does.

Calling textField.setValue("x") server-side works. But it bypasses the "value came from the client" event flow, doesn't fire the right change listeners with isFromClient() == true, doesn't enforce that the field is enabled or visible, and won't catch a bug where the form silently ignores readonly fields. The tester (and now the locator) wraps these calls with the "as a user would" semantics. That's the win you used to opt into with test(...); in the new API you can't not get it.

So the rule of thumb: interact through the locator, assert through either.

A small end-to-end

Putting all of the above together — a realistic form-submission test:

```java
@Test
void personForm_submit_recordsExpectedEntry() {
 try (var app = BrowserlessApplicationContext.create(routes)) {
 var ui = app.newUser().newWindow();
 var view = ui.navigate(PersonFormView.class);
 ui.findTextField().withLabel("Full name").setValue("Ada Lovelace");
 ui.findTextField().withLabel("Email").setValue("ada@example.com");
 ui.findButton().withCaption("Submit").click();

 // Assert against the component directly when that's the natural shape.
 Assertions.assertEquals(1, view.savedEntries().size());
 Assertions.assertEquals("Ada Lovelace",
 view.savedEntries().get(0).name());
 }
}
```

Compare against the older shape: no extends BrowserlessTest, no test(field).setValue(...) two-step, no per-test base-class configuration to manage cleanup.

Write your own locators - scale up with page objects

If your project has more than a handful of tests, consider applying the page object pattern to your browserless tests just like you would for TestBench or Playwright. The locator API was designed with this in mind: any custom Locator subclass IS a page object, and the existing tests in this repo already include one as a working template.

PersonFormLocator in the test sources is a tiny but representative example — it wraps a PersonForm composite and exposes intent-named methods instead of leaking field IDs into the test:

```java
public class PersonFormLocator extends Locator<PersonForm, PersonFormLocator> {
 public PersonFormLocator() {
 super(PersonForm.class);
 }

 public PersonFormLocator fillIn(String name, String email) {
 new TextFieldLocator().withLabel("Name").inside(this).setValue(name);
 new TextFieldLocator().withLabel("Email").inside(this).setValue(email);
 return this;
 }

 public void submit() {
 new ButtonLocator().withText("Submit").inside(this).click();
 }
}
```

Two patterns to take away:

Subclass Locator<MyComposite, MyCompositeLocator> with the recursive self-type. Filter steps inherited from Locator (withLabel, withText, inside, etc.) stay chainable and keep returning your concrete locator type.
Compose built-in locators inside the page object and scope them with inside(this). Sub-queries only see descendants of the resolved composite, so two PersonForms on the same screen don't interfere.

Tests then read at a higher level:

```java
ui.find(PersonFormLocator::new).fillIn("Ada", "ada@example.com");
ui.find(PersonFormLocator::new).submit();

Assertions.assertEquals("Submitted: Ada <ada@example.com>",
 ui.findSpan().withId("echo").getText());
```

Notice the test no longer mentions field IDs or the inner structure of the form — those are encapsulated in PersonFormLocator. When the form gets a new field, you change the page object once; every test keeps working.

The same pattern scales to whole views (LoginPageLocator, CheckoutFlowLocator), to recurring widgets across views (a custom date range picker, a hotel search bar), and to vendor components that ship as black-box Composites. For the simple "click this button" cases the built-in findButton() / findTextField() are enough — but once you find yourself repeating the same field navigation in three tests, lifting it into a custom locator is usually the right move.

A good rule of thumb: whenever you ship a custom component, ship a tiny locator next to it. Even if it starts as just a few intent-named methods over the built-in locators (fillIn, submit, selectRow), having it in place means every test that uses your component automatically benefits from the abstraction — and the locator grows naturally alongside the component as it gains features.

Why we think this is worth defaulting to

Composability over inheritance. Tests pick what they extend; the library only owns the try-with-resources.
One verb to interact. No "now wrap it" step between query and action. The locator is the action surface.
Multi-user is free. Same shape as single-user, just two ui variables. No thread-local plumbing to think about.
Familiar to Playwright users. Same mental model, mapped to Vaadin.
Better defaults. "Set this value" via a locator goes through the same path a real user click would. Direct component access stays available as an escape hatch — and is the right tool for assertions — but isn't the path of least resistance for interaction anymore.

Status and where to follow along

The existing API continues to work unchanged, so adopting the new shape is per-test, not project-wide. Naming is still settling in a few places, and the published docs trail the source a little — work-in- progress docs are visible here:

Some examples in those docs still use older names; the spirit is right, the surface is what's described above.

Feedback — especially on naming and on missing locator types for components you actually test against — is the most useful signal we can get right now. If you try the new API on a real test class, please open an issue or PR with what felt rough.

How To Ensure Serializable Sessions in Vaadin 25 Applications

tatu@vaadin.com (Tatu Lund) — Thu, 21 May 2026 14:08:49 GMT

In many real-world Vaadin 25 applications, strict session serialization isn’t always required. However, it becomes important in clustered deployments, failover setups, session passivation scenarios, and environments with frequent restarts.

The good news is that this is manageable when you apply a few disciplined patterns.

This tutorial covers the key patterns for Vaadin 25 (Flow), including Kubernetes Kit tooling, and explains UnserializableComponentWrapper for components that cannot be made serializable directly.

Why This Matters

Vaadin stores server-side UI state in VaadinSession, which is backed by HttpSession. If that session is serialized, every object reachable from the UI graph must also be serializable, or serialization/deserialization will fail.

Common symptoms when this isn’t handled well:

Random session loss after restart, rollout, or node switch. Users get logged out or lose their UI state with no obvious error
Serialization exceptions caused by hidden object references to non-serializable objects buried deep in the object graph
Deserialization failures caused by captured lambdas, anonymous listener classes, or runtime state that doesn't survive the round trip

The underlying reason these bugs are hard to detect is that Java's Serializable interface is a marker, and it makes no guarantees about the objects you reference. A class that implements Serializable can still blow up at runtime if any of its non-transient fields are not serializable. You don't find out until serialization is actually attempted.

The Core Rule

Think in object graphs, not individual classes. A class can implement Serializable, but if it references a non-serializable object that is not marked transient, session replication still fails.

The patterns below are all applications of this one principle.

Pattern 1: Make UI Graph Objects Serializable

Any object that becomes part of the live UI graph; views, presenters, component models, event handlers attached to UI components, needs to implement Serializable. This is the starting baseline.

A minimal example:

```java
public class PurchasesApprovalsPresenter implements Serializable {
 // durable state + behavior
}
```

This is necessary but not sufficient. Marking the class Serializable only tells the JVM to attempt serialization; it doesn't guarantee that all reachable state is actually serializable. That's what the remaining patterns address.

Pattern 2: Mark Runtime-Only Dependencies as transient

Service handles, executors, futures, and other runtime-only resources should not be serialized.

Minimal example:

```java
private transient PurchaseService purchaseService;
private transient CompletableFuture<Void> updateTask;
```

Why this helps:

Many service objects (especially Spring-proxied beans) are not serializable by design.
Even if they happen to be serializable, serializing them would capture stale infrastructure state (database connections, thread pools) that's meaningless after deserialization.
It keeps your serialized session lean. Accidentally serializing a service that holds a large cache can silently balloon session sizes and hurt replication performance.

Pattern 3: Rehydrate transient Fields Lazily

After deserialization, transient fields are null. If your code doesn't account for this, you'll get NullPointerExceptions in methods that previously worked fine, because they were never called on a freshly-deserialized instance before. The safest pattern is lazy rehydration through accessor methods:

```java
private PurchaseService getPurchaseService() {
 if (purchaseService == null) {
 purchaseService = PurchaseService.get();
 }
 return purchaseService;
}
```

In Spring + Kubernetes Kit setups, transient Spring-bean fields can be reinjected automatically via @SpringComponent and the Kubernetes Kit transient injection mechanism, removing the need for manual lazy initialization in many cases. See the Kubernetes Kit documentation for how to configure this.

Pattern 4: Use Serializable Callback Types

Java's standard java.util.function.* interfaces, Consumer, Supplier, Runnable, Function, do not implement Serializable. If you store instances of these in your component state, you'll get a serialization failure.

Vaadin provides serializable equivalents for the most common functional types:

```java
public interface DecisionConfirmedListener extends Serializable {
 void onConfirmed(String comment);
}
```

```java
private SerializableConsumer<Product> onSuccess;
```

Avoid plain java.util.function.* types for callback state stored in the UI graph.

Pattern 5: Clean Up on Detach

Detach is where you break references to active runtime work.

Minimal example:

```java
@Override
protected void onDetach(DetachEvent detachEvent) {
 super.onDetach(detachEvent);
 if (updateTask != null) {
 updateTask.cancel(true);
 updateTask = null;
 }
}
```

What belongs in onDetach:

Cancelling in-flight async tasks (CompletableFuture, ScheduledFuture, etc.)
Unregistering backend event listeners
Dropping strong references to any external runtime resources that the component was holding

Pattern 6: Prefer Explicit Listener Lifecycle

Event listeners deserve their own pattern because they're easy to get wrong in ways that don't immediately surface as bugs.

An unregistered listener keeps the listener object (and everything it transitively references) alive for as long as the event source lives, which may be the entire application lifetime.

```java
private transient Registration busRegistration;

@Override
protected void onAttach(AttachEvent attachEvent) {
 super.onAttach(attachEvent);
 busRegistration = eventBus.register(this::handleEvent);
}

@Override
protected void onDetach(DetachEvent detachEvent) {
 if (busRegistration != null) {
 busRegistration.remove();
 busRegistration = null;
 }
 super.onDetach(detachEvent);
}
```

Use explicit register/unregister, weak-listener approaches, or both.

Pattern 7: Enable Kubernetes Kit Session Replication Debug Tool

Vaadin 25 and Kubernetes Kit adds a development-time debug tool that serializes and deserializes the session after every request, then reports any failures to the log. This turns what would otherwise be a silent production failure into a loud, immediate development-time error.

Important: This tool is for development and diagnostics only. Do not enable it in production, it adds significant overhead to every request.

In Spring Boot projects with Kubernetes Kit, the tool is auto-configured. You can also register it explicitly

7.1 Enable in application properties

```properties
vaadin.devmode.sessionSerialization.enabled=true
vaadin.serialization.transients.include-packages=com.example.application
```

Notes:

vaadin.devmode.sessionSerialization.enabled turns on the debug tool in dev mode.
vaadin.serialization.transients.include-packages narrows transient-field inspection to your app packages.

7.2 Enable extended Java serialization diagnostics

The JVM's built-in extended debug output for serialization gives you much more detail about exactly which class in the graph caused a failure. Enable it via Maven plugin JVM arguments:

```xml
<plugin>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-maven-plugin</artifactId>
 <configuration>
 <jvmArguments>
 --add-opens java.base/java.io=ALL-UNNAMED
 -Dsun.io.serialization.extendedDebugInfo=true
 </jvmArguments>
 </configuration>
</plugin>
```

Optional timeout tuning:

```properties
vaadin.serialization.timeout=60000
```

7.3 Optional explicit registration (as in this demo)

```java
@Bean
VaadinServiceInitListener serializationDebugInitListener() {
 return new SerializationDebugRequestHandler.InitListener();
}

@Bean
@Order(Integer.MIN_VALUE)
FilterRegistrationBean<SerializationDebugRequestHandler.Filter> sessionSerializationDebugToolFilter() {
 FilterRegistrationBean<SerializationDebugRequestHandler.Filter> registration =
 new FilterRegistrationBean<>(new SerializationDebugRequestHandler.Filter());
 registration.setAsyncSupported(true);
 return registration;
}
```

7.4 Reading results

Typical outcomes in logs are SUCCESS, SERIALIZATION_FAILED, DESERIALIZATION_FAILED, and NOT_SERIALIZABLE_CLASSES.

For SerializedLambda failures, read the BEST CANDIDATES section from bottom to top to find the captured class and method.

Pattern 8: Debug Session Sizes During Serialization

In addition to pass/fail outcomes, Kubernetes Kit can help you measure serialized session size. This is useful when sessions become large and replication slows down.

8.1 Enable debug logging

This demo app enables Kubernetes Kit debug logging in application.properties:

```properties
logging.level.com.vaadin.kubernetes=debug
```

8.2 Read size from serializer log lines

Look for serializer lines that end with elapsed time and payload size in bytes.

Example:

Serializer : Serialization of attributes
[com.vaadin.flow.server.VaadinSession.springServlet,
springServlet.lock,
org.springframework.security.web.csrf.HttpSessionCsrfTokenRepository.CSRF_TOKEN,
clusterKey, SPRING_SECURITY_CONTEXT]

for session DEBUG-SERIALIZE-F159D9419778EFF9F4DD004B415083A3

with distributed key 4f1af8e8-b432-4cdc-ab98-376c8b188b99_SOURCE:F159D9419778EFF9F4DD004B415083A3

completed in 31ms (124599 bytes)

Key signal:

The value in parentheses (for example 124599 bytes) is the serialized session size for that cycle.

8.3 Practical usage

Compare size before and after opening heavy views.
Track growth over navigation flows; sudden jumps often reveal large objects captured into session state.
Use this together with serialization debug outcomes to prioritize fixes.
Disable debug-level Kubernetes logging after investigation to reduce log noise.

Pattern 9: Wrap Naturally Non-Serializable Components

Some third-party UI components are not fully serializable by nature. Vaadin Kubernetes Kit provides UnserializableComponentWrapper<S, T> for these cases.

Use this only when making the component itself serializable is not feasible.

Spreadsheet example (Apache POI workbook state)

```java
record SpreadsheetState(byte[] workbookBytes) implements Serializable {
}
Spreadsheet spreadsheet = new Spreadsheet();
var wrapper = new UnserializableComponentWrapper<SpreadsheetState, Spreadsheet>(
 spreadsheet,
 sheet -> {
 try (var out = new ByteArrayOutputStream()) {
 sheet.getWorkbook().write(out);
 return new SpreadsheetState(out.toByteArray());
 } catch (IOException e) {
 throw new UncheckedIOException(e);
 }
 },
 state -> {
 try (var in = new ByteArrayInputStream(state.workbookBytes())) {
 var workbook = new XSSFWorkbook(in);
 var restored = new Spreadsheet();
 restored.setWorkbook(workbook);
 return restored;
 } catch (IOException e) {
 throw new UncheckedIOException(e);
 }
 });
add(wrapper);
```

Important wrapper behavior:

Serializer must extract only durable, serializable state.
Deserializer rebuilds the component from scratch after graph restoration.
You must restore needed behavior (for example, listeners or runtime callbacks).
Wrapped component attach/detach listeners are still triggered.

Use Linters as an Early Warning System

Static analysis (for example SonarQube) is useful to detect classes implementing Serializable but holding non-serializable non-transient fields.

What this gives you:

Fast feedback in development and code review.
Early detection before runtime replication tests.

What it does not give you:

It cannot determine developer intent (should this field be serialized, or made transient and rehydrated?).
It won't catch failures that only manifest through object graph wiring — a field might look fine in isolation but cause failures when wired together with collaborators.

The Most Important Verification: Serialize the View Graph in Tests

Do not rely only on marker-interface checks or static analysis. The only reliable verification is serializing and deserializing a real, fully-wired view graph in an actual test.

This demo uses SerializationDebugUtil in UI unit tests:

```java
@Test
void viewGraphIsSerializable() throws IOException {
 var view = navigate(AddressesView.class);
 SerializationDebugUtil.assertSerializable(view);
}
```

Why this is more powerful than static analysis:

It validates wiring of view + presenter + collaborators in the same configuration used at runtime..
It catches real graph failures, not theoretical ones.
It helps pinpoint offending references quickly.

What Level of Coverage Is Enough?

A practical threshold for most applications:

Every major view has at least one serialization assertion covering its initial render.
Views with significant interaction states (forms, dialogs, multi-step flows) also have assertions covering those intermediate states (not just the initial render).
There are no alternate wiring paths (different constructors, feature flags, user-type variations) bypassing tested code.

A Quick Checklist You Can Use Today

UI graph collaborators implement Serializable where appropriate.
Runtime-only fields are transient.
Transient fields are rehydrated safely.
Callback and listener state uses serializable interfaces.
onDetach cleanup removes runtime work and listeners.
Kubernetes Kit debug tool is enabled in development.
Kubernetes Kit debug logging is used to track serialized session size when investigating session growth.
vaadin.serialization.transients.include-packages is scoped to app packages.
Non-serializable third-party components use UnserializableComponentWrapper with explicit serializer/deserializer.
View-level tests assert serializability after key interactions.

Final Takeaway

Serializable sessions in Vaadin 25 are not a single trick you apply once. They're the result of a consistent set of habits applied across the entire development lifecycle:

Object-graph discipline at design time: think about what belongs in a durable session state and what belongs in transient runtime resources.
Explicit lifecycle management for listeners and async work, with clean attach/detach pairs.
Continuous verification through the Kubernetes Kit debug tool during development and through serialization assertions in tests.

If you follow these patterns consistently, most production-grade session replication issues are caught early, while still keeping development ergonomics reasonable.

Happy coding!

How Eduten Built a High-Usage Learning Platform with Vaadin

lilli@vaadin.com (Lilli Salo) — Tue, 12 May 2026 09:51:24 GMT

Built on nearly two decades of research at the University of Turku, Eduten is a browser-based learning platform used in classrooms as part of weekly classroom teaching. Today, it’s used in over 50 countries and adopted in more than 70% of schools in Finland, with recognition from organizations like UNESCO and UNICEF.

Over 3 million users and up to 1 million monthly active users puts the Eduten platform firmly at national rollout scale, with high usage peaks, long lifecycles, and little room for friction in everyday workflows.

The Problem

Eduten’s challenge was turning research into something that works reliably in classrooms and homes, consistently, at scale.

Unlike many EdTech tools, Eduten is designed as a curriculum-first platform. Teachers rely on it regularly to assign exercises, track progress, and guide students.

The system has to work in real classroom conditions:

Under time pressure
Across different devices
With unreliable connectivity

From an engineering perspective, this created familiar enterprise challenges. Usage isn’t random and it follows predictable peaks during class hours. The platform supports multiple roles at once, with teachers coordinating learning, students actively interacting, and parents checking progress. And because it’s used frequently, even small issues in UX or stability become obvious immediately.

The Solution

Eduten built its platform using Vaadin’s full-stack approach with Hilla, keeping development in Java while still delivering a modern browser-based experience. Having one stack reduced the need to manage separate frontend and backend layers, so the team could focus more on the product itself.

Designing for real classroom use was just as important. The team focused on creating a digital math learning platform that works for different age groups, across countries, and on a wide range of devices.

With support from Vaadin’s design team, Eduten developed a gamified learning experience tailored to each student’s needs balancing engagement with focus.

This resulted in a platform that is:

Mobile-first – optimized for smartphones and tablets used in classrooms
Playful – interactive design that keeps students motivated
Guided – step-by-step workflows that support independent learning

This balance between playfulness and task-oriented focus ensures the platform remains engaging without compromising learning outcomes.

We had very specific requirements: we needed offline support, but we also wanted a robust Java backend. With Hilla, we've been able to deliver a much better user experience while also reducing our cloud hosting costs compared to our previous application.

– Einari Kurvinen, Head of Pedagogy, Eduten

Note: Hilla was merged into Vaadin Flow starting with Vaadin 25..

The Result

The Eduten platform is now embedded in everyday classroom use, supporting hundreds of thousands of active users with predictable, recurring demand tied to school schedules. In Mongolia alone, students completed over 2 billion math exercises in 2024, illustrating not just adoption, but sustained, high-frequency use.

More broadly, Eduten is:

Used in over 70% of schools in Finland
Deployed in more than 50 countries
Used by millions over time

From a technical perspective, the outcome is not just that the system works, but that it remains maintainable. The team can continue improving the product without introducing instability into daily classroom use.

Looking ahead

Eduten’s platform was built to last, so with a stable foundation in place, the team can focus on improving the product and gradually adding new features over time. Learn more about Eduten.

Have questions about building at scale with Vaadin?

Our team is happy to help you evaluate the right approach for your project.

Printing and Saving PDFs From Web Apps

matti@vaadin.com (Matti Tahvonen) — Wed, 29 Apr 2026 14:06:46 GMT

Printing from a browser looks trivial — until you try it. A modern web UI is built around a scrolling viewport, virtualized lists, fixed drawers and other overlays that the user never thinks about, but that a printer happily reproduces on A4. This post walks through the four options I reach for when a Vaadin app needs to produce paper (or PDFs), with runnable snippets taken from the companion wwcd demo project and notes on when each approach earns its keep.

Printing a demo view from Safari. Same DOM, one @media print stylesheet apart.

The four approaches we'll cover:

Print the live DOM, tuned with a @media print stylesheet.
Render a second, print-optimized view for content that the live UI can't reasonably paginate (virtualized Grids, certain charts, video).
Generate a PDF on the server and hand it to the user.
Bypass the OS print dialog altogether, either via Web Bluetooth in the browser or by pushing the job to a service-connected printer.

1. Just print and style with CSS

Every browser has an OS-native print dialog and a well-understood Ctrl/Cmd-P. You can trigger it from JS with window.print(), but most users already know the shortcut, so a button is usually redundant.

The real problem is that a web page was not designed for paper. Modern browsers support @media print well, and that applies to Vaadin apps just like any other HTML. If printing is a common action in your app, spend fifteen minutes on a print stylesheet — remove irrelevant chrome, adjust margins, flatten backgrounds.

In a Vaadin app, the most common obstacle is vaadin-app-layout. It's a textbook example of a layout designed for scrolling, not paper. It works fine once you know where to poke it:

```css
@media print {
 /* Hide anything the developer marks as screen-only. */
 .noprint { display: none; }

 /* Hide navbar and drawer — they waste space and break page flow. */
 vaadin-app-layout::part(navbar),
 vaadin-app-layout::part(drawer) {
 display: none;
 }

 /* app-layout precomputes padding for the drawer and doesn't recalculate
 when we hide it. Force padding to 0 and let content overflow. */
 vaadin-app-layout {
 padding-left: 0;
 overflow: visible;
 height: auto;
 }

 /* Flatten backgrounds so page 2 doesn't inherit a body gradient. */
 html,
 vaadin-app-layout vaadin-vertical-layout {
 background: none;
 border: none;
 }

 /* Make sure the dev-mode overlays never hit the page. */
 copilot-main, vaadin-dev-tools { display: none; }
}
```

If you take the CSS media query route, you'll probably want a helper class for components that shouldn't end up on paper. My demo uses .noprint (see the first rule in the block above), applied for example to the "Print" button itself — which doesn't help anyone on paper 😁:

```java
 add(new Button("Print") {{
 // See css rule below, ignore when printing using media query
 addClassName("noprint");

 getElement().executeJs("""
 // opens print the OS print dialog
 this.onclick = () => window.print();
```

Media queries can even target specific paper sizes, but resist the urge. A single layout that survives A4, Letter and the occasional label printer beats a fork per format. Rules can quickly become more difficult than your whole UI code.

1.b Print and use JS hook for preparations

With the Aura theme there's one extra quirk: the left padding is set via a CSS custom property with an animated transition, and Chromium captures the pre-transition value before the @media print rules kick in. Overriding it purely from CSS turned out to be too much for my limited 3 decades of web development experience, but hooking the beforeprint / afterprint events and nudging the padding from JS works around it:

```java
window.addEventListener("beforeprint", () => {
 document.querySelector("vaadin-app-layout")
 .shadowRoot.querySelector("[content]").style.paddingLeft = "0";
});
window.addEventListener("afterprint", () => {
 document.querySelector("vaadin-app-layout")
 .shadowRoot.querySelector("[content]").style.paddingLeft = "";
});
```

The above is not needed with the good old Lumo theme. File under "things you discover only when someone prints the page for real." Events can be handy especially if you want to slightly modify also the DOM before printing it. For Java developers, tricks below suit better in most cases though.

2. Construct a print-optimized page

Some components are architecturally incompatible with printing. The canonical example in Vaadin is the virtualized Grid: it only keeps the visible rows in the DOM and loads the rest on scroll. There is no "dear browser, please materialize all 50 000 rows before you paginate" hook. There are several other similar components out there.

When CSS can't save you, but you still need to check "printable" in your requirement docs, render a second view tailored for paper. In the demo app I keep it in the same class and branch on a constructor flag. Best approach is probably application specific.

```java
@Route // dedicated print route, no MainLayout
public class PrintOptimizedCard extends Card {

 public PrintOptimizedCard() { this(true); } // route entry — print version

 public PrintOptimizedCard(boolean optimizeForPrinting) {
 setTitle("Printing a virtualized Grid");

 if (!optimizeForPrinting) {
 // Screen version: fast, virtualized Vaadin Grid
 add(new Grid<String>() {{
 setHeight("10em");
 setItems(rows);
 addColumn(s -> s).setHeader("Str");
 addColumn(String::length).setHeader("Len");
 }});
 setHeaderSuffix(new PrintRouteButton(PrintOptimizedCard.class));
 } else {

 // Print version: plain <table> with every row
 add(new NativeTable() {{
 add(new NativeTableRow() {{
 add(new NativeTableHeaderCell("Str"));
 add(new NativeTableHeaderCell("Len"));
 }});
 rows.forEach(s -> add(new NativeTableRow() {{
 add(new NativeTableCell(s));
 add(new NativeTableCell(s.length() + ""));
 }}));
 }});
 getStyle().set("font-family", "Helvetica");
 }
 }
}
```

The "Print" button on the screen version opens the dedicated route in a hidden iframe and calls print() on it — same hack as the PDF case below, different payload:

```java
public static class PrintRouteButton extends VButton {
 public PrintRouteButton(Class<? extends Component> routeClass) {
 setIcon(VaadinIcon.PRINT.create());
 addClickListener(e -> {
 var iframe = new Element("iframe");
 iframe.getStyle().setDisplay(Style.Display.NONE);
 iframe.setAttribute("src",
 RouteConfiguration.forSessionScope().getUrl(routeClass));
 getElement().appendChild(iframe);
 iframe.executeJs("""
 this.onload = () => setTimeout(() => {
 this.focus();
 this.contentWindow.print();
 }, 500);
 """);
 });
 }
}
```

Virtually paged Grid is handy in UI, but for printed version you probably want all the rows.

3. Generate a PDF

For anything that has to look identical on every device (invoices, tickets, certificates, ID cards), the industry standard is a server-generated PDF. You pay for the extra moving part with exact control over paper size, margins, fonts and colors — including CMYK / spot colors that a browser's RGB-to-printer pipeline would happily mangle.

The Java ecosystem has plenty of PDF libraries. In the demo I reach for Apache PDFBox; OpenPDF, iText (check the license), and Flying Saucer (HTML → PDF) are reasonable alternatives depending on your needs.

A minimal PDFBox document:

```java
private static void writePDF(String content, OutputStream out) throws IOException {
 try (PDDocument document = new PDDocument()) {
 PDPage page = new PDPage(PDRectangle.A4);
 document.addPage(page);
 try (PDPageContentStream stream = new PDPageContentStream(document, page)) {
 stream.beginText();
 stream.newLineAtOffset(20, 700);
 stream.setFont(new PDType1Font(Standard14Fonts.FontName.COURIER), 12);
 stream.showText(content);
 stream.endText();
 }
 document.save(out);
 }
}
```

There are essentially two ways to hand that PDF to the user in a web app.

Option A: a plain download link. My default. Many users want the file for their digital archive, not a physical copy; a download doubles as a print preview; and it sidesteps every browser quirk in the print dialog.

```java
add(new Anchor() {{
 setText("Download 'Hello world' as PDF");
 setDownload(true);
 setHref(download -> {
 download.setContentType("application/pdf");
 writePDF("Hello world from PDF!", download.getOutputStream());
 });
}});
```

Option B: the hidden-iframe print trick, for a desktop-app feel where clicking "Print invoice" opens the OS print dialog directly with the PDF loaded. The Viritin add-on ships it as PrintPdfButton:

```java
add(new PrintPdfButton(out -> writePDF("This is directly printed PDF", out)));
```

The downside of Option B: a user who only wants to archive the document has to go through the OS dialog's "Save as PDF" path. If archiving is a common case, stick with Option A.

4. Skip the OS print dialog entirely

Sometimes the OS dialog is in the way — you want automation, or the printer is physically elsewhere. Classic use cases:

A hotel self check-in kiosk dropping a receipt on a lobby printer.
A warehouse picker scanning items and printing labels on a fixed Dymo.
A field service tech submitting a job from their phone to a printer back at the office.

The great thing in this approach is that the print job no more needs to be triggered by a direct user interaction in the computer. They can be scheduled or automatically triggered by another hardware interaction. In a recent hobby app I'm initiang a label printing automatically when a Bluetooth scale (also accessed via WebBluetooth) gets a solid reading.

The job naturally has to reach the device some other way. Two example paths:

4a. Talk to the printer from the browser (Web Bluetooth)

Chromium-based browsers can pair with some Bluetooth LE printers directly via the Web Bluetooth API. The browser handles pairing; your code writes bytes to a characteristic. Good fit for handheld label printers where each user has their own device.

In the demo app, DymoLetraTag200B add-on wraps the pairing + characteristic writes as a hidden Vaadin component. The server side is mercifully thin:

```java
var name = new VTextField("Text");
name.setValue("Vaadin");

var printer = new DymoLetraTag200B();
add(printer); // must live in the component tree

add(new HorizontalFloatLayout(name, new Button("Print using Dymo LetraTag 200B",
 e -> printer.print("}> " + name.getValue()))));

The Chrome Bluetooth pairing dialog listing a "LetraTag" device and the label printer in action

Two older community examples worth a look:

flow-bluetooth-printer
Vaadin Point-of-Sale AI demo — a more recent, vibe-coded exploration.

Limits: Firefox and Safari don't ship Web Bluetooth, the pairing UX surprises first-time users, and every printer model needs its own protocol wrapper. Works great if you control the hardware and the browser — kiosk, warehouse tablet, company-issued phones. Less great as a general public-internet feature.

4b. Print from the server (or a custom service)

The most undervalued option. If your users are on known networks, or if "the receipt shows up within a minute" is good enough, server-side printing is almost always simpler to operate than client-side Bluetooth.

From Linux, the brute-force approach is still fine:

```bash
lp /tmp/generated.pdf
```

One Runtime.exec, one temp file, done — provided the printer is configured and reachable from the server. For anything more structured, cups4j lets you submit jobs, query queues, and list printers from Java. Many modern office printers expose a CUPS endpoint themselves, so no intermediate print server is required — just a hole in the firewall.

For printers that can't reach the server, flip the connection: let the printer side open a socket to the server instead. In the demo, a small Raspberry Pi talks BLE to the same Dymo as above (it could just as well drive a regular office printer) and registers itself over a WebSocket. The server broadcasts jobs on that socket; the Pi does the BLE write locally.

A minimal implementation — one Spring @Service that doubles as a TextWebSocketHandler:

```java
@Service
public class RemotePrinterService extends TextWebSocketHandler {

 private final Set<WebSocketSession> printers = new CopyOnWriteArraySet<>();

 public boolean printerAvailable() { return !printers.isEmpty(); }

 public void print(String text) {
 TextMessage msg = new TextMessage(text);
 for (WebSocketSession s : printers) {
 try {
 synchronized (s) { s.sendMessage(msg); }
 } catch (IOException e) { printers.remove(s); }
 }
 }

 @Override public void afterConnectionEstablished(WebSocketSession s) { printers.add(s); }
 @Override public void afterConnectionClosed(WebSocketSession s, CloseStatus c) { printers.remove(s); }
}
```

```java
@Configuration
@EnableWebSocket
class PrinterWebSocketConfig implements WebSocketConfigurer {
 private final RemotePrinterService service;
 PrinterWebSocketConfig(RemotePrinterService s) { this.service = s; }

 @Override public void registerWebSocketHandlers(WebSocketHandlerRegistry r) {
 r.addHandler(service, "/ws/printer").setAllowedOriginPatterns("*");
 }
}
```

From a Vaadin view you don't see the WebSocket at all — it's just a method call:

```java
if (remotePrinterService.printerAvailable()) {
 remotePrinterService.print(LocalDateTime.now() + " @ server time");
 Notification.show("Print job sent");
} else {
 Notification.show("Printer offline");
}
```

The Raspberry Pi side is beside the point of this post, but if you're curious the Java sources are on GitHub (yes, modern Java runs great even on a $15 Pi Zero 2W with 512mb of memory 😎).

Architecture at a glance:

The key detail: the WebSocket is dialed from the Pi outward, not from the server inward. The printer can sit behind any NAT / firewall the office already has — no inbound ports, no VPN, no static IP. The server only ever answers connections; it doesn't have to find the printer.

Nothing about this pattern is BLE-specific. Swap the Pi for a workstation on an office LAN, the BLE write for a lp call, and you have the same design for any USB or network printer — without needing any firewall adjustments. Just be sure to complete the PoC with some security adjustments or I'll be printing your secret documents with my Dymo 🤓.

Picking an approach

Need	Reach for
Occasional print of an existing view	`@media print` + `.noprint`
Printing a virtualized Grid or chart	Dedicated print route + iframe trick
Pixel-perfect documents, archival	Generated PDF + download link
Desktop-app feel, one-click print	Generated PDF + `PrintPdfButton`
Direct-to-label, controlled hardware	Web Bluetooth
Fixed printers, automation, remote locations	Server-side (`lp` / cups4j / WebSocket bridge)

None of these is wrong — they optimize for different things. Start from the user's actual need ("do they want the paper, the file, or the automation?") and the integration pressure falls into place.

The Definitive Guide to Modernizing Java Swing Applications in 2026

Roman Kałkowski — Fri, 24 Apr 2026 13:36:43 GMT

Java Swing has been the workhorse of enterprise desktop applications for more than two decades. It powered internal tools, financial platforms, logistics systems, and ERP front-ends across industries where reliability mattered more than aesthetics. And for a long time, that bargain held.

It no longer does.

Oracle stopped active development of Swing years ago. The framework still receives security patches and critical bug fixes, but no new capabilities are being built. Meanwhile, every force shaping enterprise software—cloud-native architecture, remote workforces, mobile-first expectations, and a generational shift in the developer talent pool—is pulling in the opposite direction from a desktop-only UI toolkit.

If you are responsible for a Java Swing application in 2026, the question is not whether to modernize. It is how to modernize without destroying the business logic, domain expertise, and institutional knowledge embedded in your existing codebase.

This guide lays out the three primary migration approaches, provides a decision framework for choosing between them, and walks through the timelines, risks, and architectural considerations that determine whether a Swing modernization project succeeds or stalls.

Why Swing Applications Need Modernization Now

Before diving into strategies, it is worth understanding the converging pressures that have made Swing modernization urgent rather than aspirational. These are not theoretical concerns—they are operational realities that compound with each year of delay.

The Talent Gap Is Already Here

The developer ecosystem has moved decisively to web-based frameworks. Computer science programs do not teach Swing. Bootcamps do not cover AWT layout managers. Every developer entering the workforce in 2026 has never written a line of Swing code and has no interest in starting.

For organizations maintaining large Swing codebases, this creates an acute hiring problem. The pool of experienced Swing developers is shrinking through retirement and attrition. Replacements are expensive to find and even more expensive to retain, because those developers know their skills are scarce. Every year you wait, the talent market gets worse.

User Experience Expectations Have Shifted Permanently

Enterprise users in 2026 use Microsoft 365, Salesforce, SAP, and ServiceNow, Figma, Slack in their daily workflows. They interact with polished, responsive web interfaces that adapt to their screen size, support dark mode, and provide real-time collaboration. Then they switch to an internal Swing application that looks and feels like it was designed in 2005—because it was.

This is not vanity. Poor UX in internal tools reduces adoption, increases training costs, drives workarounds in spreadsheets, and quietly erodes data quality. When a logistics coordinator avoids the "official" tool because the web-based alternative is faster, you have a modernization problem masquerading as a data governance problem.

The Operational Overhead of Desktop Swing Applications

Desktop Swing applications carry significant operational overhead that web-based applications simply do not. Every deployment requires installing and managing a Java runtime on each user's machine. Every version update must be pushed to every endpoint. IT teams must maintain compatibility across different operating systems, hardware configurations, and Java versions. Remote access requires VPN or remote desktop infrastructure—itself a cost and security consideration.

As organizations move to cloud platforms like AWS, Azure, or GCP, the operational gap becomes even more visible. Web applications deploy instantly, scale automatically, and require zero client-side installation. Swing applications do none of these things. The overhead of managing desktop installations across a workforce—patching, version control, OS compatibility—represents a meaningful cost that compounds with every passing year.

Security Risks Are Expanding, Not Shrinking

Swing desktop applications carry a security profile that is increasingly difficult to defend in a modern threat landscape. Every client machine runs a full JVM with broad default permissions—access to the local file system, network, and external processes—creating a wide attack surface that must be secured and patched on every individual device. Oracle continues to issue Critical Patch Updates for Java SE quarterly, addressing vulnerabilities like CVE-2025-50106, CVE-2025-30749, and CVE-2025-30761 in recent cycles alone. Each patch must be deployed to every client installation, and any machine that falls behind becomes a potential entry point.

The architectural patterns common in Swing applications compound the problem. Many Swing clients hold database credentials locally or establish direct JDBC connections to back-end databases, bypassing the API layers and authentication gateways that modern web application security architectures rely on. Connection strings embedded in client-side configuration files, unencrypted local caches of sensitive data, and JVM processes running with unrestricted permissions are not theoretical risks—they are the reality of how many Swing applications were built in an era when every user sat on a trusted corporate network.

Centralizing the application on the server—as both Phase 1 of the Vaadin Swing Modernization Toolkit and a full web migration achieve—eliminates the client-side JVM entirely. Database connections stay behind the firewall. Credentials never leave the server. Patching happens once, centrally, instead of across hundreds or thousands of client machines. The security posture improves immediately and structurally, not just incrementally.

Accessibility and Regulatory Compliance Are No Longer Optional

The regulatory landscape has shifted decisively. The European Accessibility Act (EAA), enforceable since June 28, 2025, requires businesses operating in the EU digital market to meet EN 301 549 accessibility standards—which incorporate WCAG 2.1 Level AA. In the US, Section 508 and ADA-related litigation continue to expand the scope of digital accessibility obligations. Organizations that provide software to government agencies, financial institutions, healthcare systems, or public-facing services are increasingly required to demonstrate accessibility compliance as a condition of procurement.

Java Swing was never designed with web accessibility standards in mind. Swing components have their own accessibility API (the Java Accessibility API), but it does not map cleanly to WCAG criteria, ARIA roles, or the assistive technology ecosystem that has standardized around web content. A Swing application cannot produce a VPAT (Voluntary Product Accessibility Template) that meets WCAG 2.1 AA in any meaningful sense, because the framework does not generate the semantic HTML, keyboard navigation patterns, or screen reader hooks that the standard requires.

This is not a cosmetic gap. For organizations selling into the EU market, serving government clients, or operating in regulated industries, a Swing front end is becoming a compliance liability. Modern Java web frameworks like Vaadin provide WCAG 2.1 AA certified components out of the box—migrating to web views does not just improve the user experience, it resolves a regulatory exposure that will only grow more acute as enforcement matures.

The Cost of Waiting Is Compounding

Legacy maintenance is not a flat cost. It compounds. Each year of deferred modernization means more code written against deprecated APIs, more institutional knowledge concentrated in fewer people, and more technical debt layered onto a foundation that is not receiving investment. The longer you stay on Swing, the more expensive any future change becomes—whether that is hiring, migrating, or simply maintaining what you already have.

The Three Modernization Approaches

Every Swing modernization project falls into one of three categories. Each has distinct cost profiles, risk characteristics, and timelines. Understanding the trade-offs is essential before committing resources.

Approach 1: Lift-and-Shift (Run Swing in the Browser)

The fastest path to web-based access is to run the existing Swing application on a server and stream its rendered output to a web browser. The Vaadin Swing Modernization Toolkit supports this as its first phase, acting as a bridge between the Java application and the browser. The Swing UI renders on the server and is delivered to the client via the browser, with user interactions relayed back transparently.

How it works: The application continues to run as a standard Swing application on a server-side JVM. A rendering layer captures the visual output and streams it to the browser. Mouse clicks, keystrokes, and other input events are captured in the browser and sent back to the server. From the application's perspective, it is running on a desktop—it simply does not know the "desktop" is actually a remote browser session. Minor modifications are needed to support multi-tenancy—ensuring the application can safely serve multiple concurrent users from a single server process—and to handle web-appropriate session lifecycle (timeouts, browser navigation).

Advantages:

Minimal source code modification required. The existing application runs largely as-is, though some changes are needed to enable multi-tenancy (serving multiple users from a single JVM).
Fastest time to browser-based access—often measurable in hours or days, not weeks or months, depending on the complexity of multi-tenancy adaptations. Ongoing server infrastructure costs scale with concurrent users.
Eliminates the need to install or manage a Java runtime (JVM) on every user's machine—users access the application through any standard web browser.
Enables remote access and centralized deployment immediately.

Limitations if you stop here:

The visual design and interaction model do not improve. The application still looks and behaves like a desktop application—rendered in a browser window but not redesigned for it. The deployment model changes (from a locally installed desktop app to a browser-accessible service), which is itself a meaningful improvement, but the UI does not adapt to screen sizes, support modern interaction patterns, or feel like a native web application.
Server resource requirements are significant. The JVM moves from each client machine to a centralized server—but each concurrent user session still runs a full Swing application instance on that server, consuming CPU, memory, and network bandwidth proportional to the complexity of the UI.
The deployment model changes—from a locally installed desktop application to a centrally deployed, browser-accessible service. This brings real operational benefits: easier updates, reduced IT overhead, and remote access. However, the underlying application modernization remains untouched. The technology debt is still there; only the delivery mechanism has changed.

The critical distinction is whether lift-and-shift is your end state or your starting point. Some tools treat browser-based rendering as the final destination, leaving you with a streamed desktop UI and no path forward. The Vaadin Swing Modernization Toolkit treats it as Phase 1—a foundation that unlocks incremental screen-by-screen modernization (Approach 2 below). You get browser access in weeks, then continue modernizing without starting over.

Best suited for: Organizations that need browser access urgently (regulatory, remote access mandates) as a first milestone, with the option to continue modernizing incrementally. Also appropriate for applications with a limited remaining lifespan where deeper investment is not justified.

Typical timeline: Hours to days for browser-based access, depending on the complexity of multi-tenancy adaptations. Ongoing server infrastructure costs scale with concurrent users.

Approach 2: Incremental Migration (Screen-by-Screen Modernization)

The incremental approach replaces individual Swing views with modern web views one screen at a time, while keeping the rest of the application functional. This is the strategy that balances risk reduction with genuine modernization—you are improving the application continuously rather than waiting for a big-bang replacement.

How it works: If you have already completed a lift-and-shift (Approach 1), you are ready to begin. If not, the process starts the same way: the application is adapted to run on a server with its UI accessible in a browser. Then, individual screens are rebuilt using a modern Java web framework. During the transition period, users interact with a mix of legacy Swing views and new web views within the same application. Business logic, services, and domain models remain intact throughout—only the presentation layer changes.

Vaadin's Swing Modernization Toolkit is purpose-built for this two-phase approach. Phase 1 delivers browser access. Phase 2 provides automation to help convert Swing UIs into modern Java web views built with Vaadin. Both Swing views and new web views coexist during the transition, so the application remains fully functional at every stage.

Advantages:

Risk is distributed across the project timeline. Each screen migration is a small, bounded deliverable. If priorities shift, you can pause the migration and still have a partially modernized, fully functional application.
Business logic is preserved. The existing Java services, domain models, and back-end integrations do not need to be rewritten. Only the UI layer changes.
User experience improves incrementally. High-traffic or high-pain screens can be prioritized first, delivering visible value early.
The team learns as it goes. Lessons from early screen migrations inform later ones, reducing the error rate and increasing velocity over time.
Automation reduces manual effort. Vaadin's toolkit automates the conversion of many common Swing UI patterns to web equivalents, preserving logic, structure, and even code comments.

Disadvantages:

Requires adaptation of the existing application for server-side multi-tenancy and browser-based rendering before incremental screen replacement can begin.
The coexistence of Swing and web views means maintaining two rendering paradigms during the transition period, which adds some complexity.
Total project duration is longer than a clean rewrite in theory (though shorter in practice, because rewrites almost always exceed their estimates).

Best suited for: Organizations with large, business-critical Swing applications that cannot tolerate downtime or a prolonged parallel-run period. Also ideal when the existing Java business logic is sound and the primary modernization need is in the UI layer.

Typical timeline: Phase 1 (browser access) in 4–8 weeks. Phase 2 (screen-by-screen migration) runs over 6–24 months depending on application size and team capacity. Most teams migrate 2–4 screens per sprint once they hit their stride.

Approach 3: Full Rewrite

The full rewrite discards the existing codebase and rebuilds the application from the ground up using a modern technology stack. This is the approach that gets proposed most often in executive strategy meetings and succeeds least often in practice.

How it works: A new application is designed and built to replace the existing Swing application entirely. The technology stack is chosen freely—React, Angular, or a Java web framework like Vaadin on the front end; Spring Boot, Quarkus, or Micronaut on the back end. The existing Swing application continues to run in production until the replacement is feature-complete and validated, at which point users are cut over.

Advantages:

Complete architectural freedom. You can adopt modern patterns (microservices, event-driven architecture, API-first design) without being constrained by legacy decisions.
No legacy code to carry forward. The new codebase starts clean.
Opportunity to rethink workflows, not just replicate them. A rewrite can simplify overly complex screens, eliminate unused features, and redesign processes around current business needs.

Disadvantages:

High risk of failure. Industry data consistently shows that large-scale rewrites take 2–3 times longer than estimated, cost 2–4 times more than budgeted, and frequently fail to reach feature parity with the application they are replacing. The Standish Group's research on large IT projects reinforces that the larger and longer the project, the lower its chance of success.
Loss of embedded domain knowledge. Legacy codebases contain years of business rule refinements, edge case handling, and integration workarounds that are not documented anywhere except in the code itself. Rewrites lose this knowledge, and the loss usually surfaces as defects in production.
Extended parallel-run period. The existing Swing application must remain operational and maintained throughout the rewrite, doubling the team's maintenance burden.
Opportunity cost. Every developer working on the rewrite is not working on new features, integrations, or improvements that could deliver business value today.
API layer overhead. A rewrite using a JavaScript front end (React, Angular) requires designing and maintaining a REST or GraphQL API between the front end and back end—a significant ongoing engineering cost that did not exist in the original Swing architecture and does not exist in a Vaadin Flow migration.

Best suited for: Applications that are small enough to rewrite within 6–12 months, applications where the business logic itself needs to change fundamentally (not just the UI), or situations where the existing codebase is so deteriorated that incremental migration is not feasible.

Typical timeline: 12–36 months for enterprise applications. Budget for 2x the initial estimate as a realistic baseline.

Decision Framework: Choosing Your Approach

The right approach depends on your specific constraints. Use the following factors to guide your decision.

Factor 1: Application Size and Complexity

Small applications (under 50 screens, limited integrations) can tolerate a rewrite. The risk is manageable because the scope is bounded. Large applications (hundreds of screens, deep integrations with ERP, databases, and external systems) are almost always better served by incremental migration. The rewrite risk for a large application is simply too high for most organizations.

Factor 2: Quality of Existing Business Logic

If your Java business logic is well-structured—clean service layers, reasonable separation of concerns, tested domain models—then preserving it through incremental migration is the efficient choice. You are leveraging years of refinement rather than recreating it from scratch.

If your business logic is tangled into Swing event handlers with no separation of concerns, incremental migration is harder (though still possible with refactoring). A rewrite may be more appropriate if the codebase is fundamentally unsalvageable.

Factor 3: Time to Value

How quickly do you need to show results?

Hours to days: Lift-and-shift gives you browser access immediately.
Weeks to months: Incremental migration delivers visible improvements on a continuous basis, with browser access as the first milestone.
Months to years: A full rewrite delivers nothing until it is finished, and it is not finished until it reaches feature parity.

Most stakeholders and sponsors have a limited appetite for long projects with no intermediate deliverables. Incremental migration aligns better with how organizations actually fund and govern IT initiatives.

Factor 4: Team Composition

If your team is primarily Java developers, an approach that preserves the Java stack is significantly less disruptive. Incremental migration with a Java web framework like Vaadin means the team can be productive immediately without learning an entirely new language and ecosystem.

If you are building a new team or the existing team is already fluent in modern JavaScript frameworks, a rewrite using React or Angular may be viable—but factor in the back-end transition cost as well.

Factor 5: Budget and Risk Tolerance

Lift-and-shift has the lowest upfront cost but does not solve the underlying problem. Incremental migration has a moderate and predictable cost that scales linearly with the number of screens migrated. Full rewrites have the highest cost, the widest variance in actual-vs-estimated spend, and the highest risk of failure.

Decision Matrix

Factor	Lift-and-Shift	Incremental Migration	Full Rewrite
Time to browser access	Hours–days	4–8 weeks	12–36 months
UX improvement	None	Continuous	All at once (if completed)
Business logic preserved	Yes (untouched)	Yes (reused)	No (rewritten)
Risk level	Low	Low–Medium	High
Cost predictability	High	High	Low
Team disruption	Minimal	Moderate	Significant
Long-term technical debt	Unchanged (unless you continue to Phase 2)	Eliminated incrementally	Eliminated (if completed)
Path to full modernization	Yes, via incremental migration	Built in	Yes (if completed)
Scales to large apps	Yes	Yes	Poorly

Architecture: What the Incremental Migration Looks Like

Because incremental migration is the recommended approach for most enterprise Swing applications, it is worth understanding the architecture in more detail.

Phase 1: Browser-Based Access

The existing Swing application is deployed to a server environment. The Swing Modernization Toolkit handles rendering the Swing UI in the browser and managing user sessions. Minor modifications are required to support multi-tenancy (multiple users running concurrent sessions) and web-appropriate behaviors (session timeout, browser navigation, etc.).

At the end of Phase 1, users access the application through a URL instead of a locally installed client. The application looks the same as before—but it now runs centrally, can be accessed from any device with a browser, and no longer requires a JVM on client machines.

This phase is not cosmetic. It solves real operational problems immediately. IT teams can deploy updates centrally instead of pushing installers to every client machine. Access control moves to URL-based authentication rather than per-machine configuration. Users working remotely—a permanent reality in most organizations—can access the application from any browser without VPN tunneling to a specific desktop.

Phase 2: Screen-by-Screen Replacement

With browser access established, the team begins replacing Swing views with modern web views. The toolkit provides automation that converts many Swing UI patterns—layouts, input fields, tables, dialogs—to their Vaadin web equivalents. Code structure, comments, and logic flow are preserved during the conversion.

Each migrated screen goes through a standard workflow: automated conversion, manual review and refinement, testing, and deployment. The application in production always contains a mix of remaining Swing views and completed web views. Users experience a progressively modernized interface with each release.

Teams typically prioritize screens based on a combination of user traffic, business criticality, and migration complexity. The highest-value, lowest-complexity screens go first, building team confidence and establishing patterns that accelerate later migrations.

This is where the Java advantage becomes decisive. Because Vaadin Flow is a server-side Java framework, your existing Java developers write the new web views in the same language, on the same build system, using the same IDE they already know. There is no context-switching to JavaScript, no REST API layer to design between front end and back end, and no separate front-end build pipeline to maintain. The migration is a Java-to-Java transformation, which fundamentally changes the The toolkit integrates with standard Maven and Gradle builds, so it fits into existing CI/CD pipelines without requiring a parallel front-end toolchain. skills equation compared to approaches that require adopting an entirely new technology stack.

Phase 3: Completion and Swing Removal

Once all screens have been migrated, the Swing rendering layer is removed entirely. The application is now a standard modern Java web application running on Vaadin Flow, with all the advantages of a web-native architecture: responsive layouts, accessibility compliance, modern component libraries, and standard web deployment.

At this point, the application is indistinguishable from one that was built as a web application from the start. It can be deployed in containers, scaled horizontally behind load balancers, and integrated into CI/CD pipelines using standard tooling. The Swing dependency—and all the operational and talent constraints that came with it—is gone.

Common Objections and How to Address Them

Enterprise modernization projects inevitably face internal resistance. Here are the objections that surface most frequently and how to think about them.

"Our Swing application works fine. Why change it?"

It works fine today, with the current team. The question is whether it will work fine in three years when two of your senior Swing developers have retired and the remaining team spends 60% of its time on maintenance rather than improvements. Modernization is not about fixing something broken—it is about preventing a predictable failure before it becomes an emergency.

"We tried a rewrite before, and it failed."

Many organizations carry the scars of a previous rewrite attempt. This is actually an argument for incremental migration, not against modernization. The incremental approach was designed specifically to avoid the failure modes of big-bang rewrites: unbounded scope, loss of business logic, and extended periods with no deliverable output. Every sprint produces a working, improved application.

"Can we just use AI to rewrite everything?"

AI-assisted code transformation is a legitimate tool in the modernization toolkit, and some vendors are exploring this space. However, the challenge with Swing modernization is not primarily a code generation problem. It is an architecture problem—how do you transition a desktop application to a web deployment model while preserving business logic and maintaining continuity of service? Automated code translation can accelerate individual screen conversions (and the Vaadin toolkit uses automation for exactly this purpose), but it does not replace the architectural strategy, phased deployment plan, and organizational change management that determine whether a modernization project succeeds.

"We should skip Java web frameworks and go straight to React or Angular."

This is viable if you are willing to rewrite your back end as well, hire or retrain your team in JavaScript/TypeScript, and accept the timeline and risk profile of a full rewrite. For organizations whose core competency is Java—and whose team knows Java—staying in the Java ecosystem for the front end eliminates an enormous category of project risk and dramatically shortens the timeline to first results. (For a detailed comparison, see Java Swing alternatives for building modern web apps.) Beyond the language switch, the JavaScript ecosystem introduces its own complexity: npm dependency management, frequent framework version upgrades, bundler configuration, and a front-end build pipeline that must be maintained alongside your Java back end. For teams accustomed to the relative stability of the Java ecosystem, this is not a trivial operational change.

Risk Matrix

Every modernization approach carries risks. Identifying them early allows you to mitigate them structurally rather than reactively.

Risk	Lift-and-Shift	Incremental	Full Rewrite
Project failure / cancellation	Low	Low	High
Loss of business logic	None	None	Significant
Scope creep	Low	Medium	Very High
Extended timeline	Low	Medium	Very High
User disruption during transition	Low	Low (gradual)	High (big-bang cutover)
Talent dependency on legacy skills	Unchanged	Decreasing over time	Eliminated (but new skills required)
Integration breakage	None	Low (APIs preserved)	High (new integrations)

Timeline Estimates by Application Size

These estimates assume a typical enterprise context: a dedicated team of 3–6 developers, standard code review and QA processes, and normal organizational decision-making cadence.

Application Size	Lift-and-Shift	Incremental Migration	Full Rewrite
Small (10–30 screens)	1–3 weeks	3–6 months	6–12 months
Medium (30–100 screens)	2–6 weeks	6–12 months	12–24 months
Large (100–300 screens)	4–8 weeks	12–24 months	24–36+ months
Very Large (300+ screens)	6–12 weeks	18–36 months	36–60+ months (high failure risk)

Note that for incremental migration, these timelines include Phase 1 (browser access). Visible modernization begins within the first few months and continues on a predictable cadence throughout the project.

What a Successful Migration Project Looks Like

Having guided numerous organizations through Swing modernization, a pattern emerges in the projects that succeed.

Weeks 1–4: Assessment and architecture. The team inventories the existing application—screens, integrations, business logic layers, and technical debt. They select the migration approach, define the Phase 1 scope, and set up the server infrastructure for browser-based access.

Weeks 4–8: Phase 1 delivery. The existing Swing application goes live in the browser. Users get remote access. IT gets centralized deployment. The team has now delivered a tangible result to stakeholders, which builds confidence and sustains funding for Phase 2.

Months 3–6: First wave of screen migrations. The team migrates the highest-priority screens—typically the ones that users interact with most frequently or that cause the most support tickets. These early migrations establish the team's conversion patterns, testing strategies, and deployment cadence. Velocity typically doubles between the first and third screen migration as the team internalizes the toolkit's automation capabilities.

Months 6–18+: Steady-state migration. The team settles into a predictable rhythm of 2–4 screens per sprint. Each release is a small improvement, each sprint reduces the remaining Swing surface area, and each month the application looks and feels more modern. The organization can adjust pace, reprioritize screens, or pause without losing progress.

Final milestone: Swing removal. The last Swing view is replaced, the rendering bridge is removed, and the application is a fully modern Java web application. For many organizations, this moment is anticlimactic—by the time it arrives, 90% of the application has already been modernized and running smoothly in production for months. (For a real-world example of this pattern, see how IZUM migrated over 1,000 Swing views with 90% code reuse.)

Getting Started: A Practical First Step

If you are evaluating how to modernize a Java Swing application, the most productive first step is an assessment of your current codebase. This assessment should answer:

How many screens does the application have, and which are most heavily used?
How cleanly is business logic separated from the Swing UI layer?
What external integrations exist, and how are they accessed?
What is the current server infrastructure, and what constraints does it impose?
What is the team's familiarity with modern Java web frameworks?

These inputs feed directly into the decision framework above and allow you to estimate timelines, costs, and risks with reasonable accuracy.

You do not need to answer these questions alone. Vaadin offers a Swing modernization assessment that evaluates your application against these criteria and provides a concrete recommendation with a preliminary migration plan, including timeline estimates and resource requirements. If you are managing a Swing application and considering modernization, this is the fastest way to move from "we should do something" to "here is what we should do, how long it will take, and what it will cost."

How To Style Vaadin Components for Both Aura and Lumo

tatu@vaadin.com (Tatu Lund) — Thu, 16 Apr 2026 11:39:03 GMT

By default, Vaadin components are rendered with minimal base styles. These provide a neutral foundation—useful when you want to build a custom theme from scratch or create a look that differs from the built-in options.

Vaadin comes with two main themes: Lumo and Aura. Lumo is the original theme, built around a flexible set of design tokens and supporting variants like dark mode and compact density. Aura, introduced more recently, offers a more modern and polished visual style out of the box.

Lumo theme in light and dark mode.

Styling for just one of these themes is usually straightforward. The challenge begins when you need your custom components to work seamlessly across both.

That’s where things can start to drift. Components may look correct in isolation, but small differences in spacing, focus styles, or states can make the overall UI feel inconsistent.

This guide presents a practical, production-ready approach for styling Vaadin components so they work cleanly in both Aura and Lumo. It focuses on three real integration styles from this project:

Color Picker (custom Lit web component)
Bean Table (server-side component with custom DOM)
Pivot Table (third-party JavaScript widget through connector)

The main goal is visual cohesion: custom components should feel native next to standard Vaadin components in both Aura and Lumo.

What visual cohesion means in practice

Visual cohesion isn’t about pixel-perfect matching—it’s about consistency in how components behave and communicate state.

In practice, users don’t consciously compare components. Instead, they pick up on subtle UX cues. When those cues are inconsistent, the UI feels fragmented—even if every individual component looks fine on its own.

In practice, cohesion is measured by whether custom and built-in fields share the same UX cues:

Required indicator behavior – How required fields are marked (asterisk, placement, spacing). Inconsistencies here make forms feel uneven and harder to scan.
Focus treatment – The visual language for focus—ring, border, shadow, or combination. This is critical for both usability and accessibility, and mismatches are immediately noticeable.
Read-only and disabled affordances – How non-interactive fields are presented. Differences in opacity, contrast, or styling can confuse users about what is editable.
Invalid state contrast and border handling – Error colors, border styles, and contrast. These need to feel consistent across components to maintain clarity and trust.
Dialog/popup surfaces, radii, and elevation – Background colors, border radius, and elevation (shadows). These define the overall “material feel” of the UI and are especially noticeable when mixing components.

If these elements behave consistently, custom and built-in components feel like part of the same system. If they don’t, the UI starts to feel stitched together, even if the differences are subtle.

The global color scheme for Aura is either light or dark, depending on the operating system preference.

Core architecture rule

To make this work in practice, you need a clear separation between what stays the same and what changes across themes.

The guiding principle is simple: use one behavior path and one structural DOM path, and let the theme handle only the visual layer.

That means:

The base structure and behaviour of your component stay the same regardless of theme Theme detection is thin and explicit.
Styling is token-driven through internal component variables.

This approach keeps maintenance predictable as both themes evolve.

Pattern map by component type

How you apply this pattern depends on the type of component you’re working with – keep it simple and choose the smallest pattern that fits your component architecture.

For Lit-based web components): Use ThemeDetectionMixin, style with host selectors, reflect state to host attributes.
For server-side custom components: Detect active theme from root CSS markers, add root class (aura or lumo), scope CSS under that class.
With third-party JS libraries: Keep vendor CSS as baseline, then override under .aura ... and .lumo ... with Vaadin tokens.
Finally, for extended Vaadin components (for example checkbox as toggle): Use theme variant + ::part(...), and a fallback chain (lumo -> aura -> literal).

Foundation styling pattern for all implementations

Start with internal component tokens and consume only those in shared rules.

```css
.my-component,
:host {
 --my-text-color: var(--vaadin-text-color);
 --my-border-radius: var(--vaadin-radius-m);
 --my-focus-ring-color: var(--vaadin-focus-ring-color);
 --my-padding-s: var(--vaadin-padding-s);
}

.my-component .field,
:host .field {
 color: var(--my-text-color);
 border-radius: var(--my-border-radius);
}

.lumo.my-component,
:host([data-application-theme="lumo"]) {
 --my-border-radius: var(--lumo-border-radius-m);
 --my-padding-s: var(--lumo-space-s);
}

.aura.my-component,
:host([data-application-theme="aura"]) {
 --my-border-radius: var(--vaadin-radius-m);
 --my-padding-s: var(--vaadin-padding-s);
}
```

This removes the need to duplicate full CSS blocks per theme.

Example 1: Color Picker (Lit web component)

Let’s start with the most straightforward case: a Lit-based component.

Color Picker uses ThemeDetectionMixin(ThemableMixin(LitElement)).

Theme is exposed as data-application-theme on host.
CSS uses host selectors for Aura and Lumo.
State is reflected to the host (invalid, readonly, disabled, required, compact flags).

Minimal pattern:

```typescript
export class MyComponent extends ThemeDetectionMixin(ThemableMixin(LitElement)) {
 static get is() {
 return "my-component";
 }
}
```

´´´css
:host([data-application-theme="aura"][invalid]) .field {
 border-color: var(--vaadin-error-color);
}

:host([data-application-theme="lumo"][invalid][disabled]) .field {
 opacity: 0.7;
}
```

If your component contains nested Vaadin components, make sure to forward the theme so everything stays in sync:

```typescript
<vaadin-custom-field theme="${ifDefined(this.theme)}">
 <vaadin-combo-box theme="${ifDefined(this.theme)}"></vaadin-combo-box>
</vaadin-custom-field>
```

Example 2: Bean Table (server-side custom DOM)

For server-side components, the approach is slightly different. Bean Table cannot use ThemeDetectionMixin because it is not a Lit web component. Instead, it detects the theme on attach and adds class names to the component root.

```java
@CssImport("./my-component.css")
public class MyComponent extends Composite<Div> {
 @Override
 protected void onAttach(AttachEvent event) {
 super.onAttach(event);
 getElement().executeJs(
 "const s=getComputedStyle(document.documentElement);" +
 "const t=s.getPropertyValue('--vaadin-aura-theme').trim()==='1'?'aura':" +
 "(s.getPropertyValue('--vaadin-lumo-theme').trim()==='1'?'lumo':'');" +
 "if(t){this.classList.add(t);}"
 );
 }
}
```

CSS then stays cleanly scoped:

```css
.my-component {
 /* shared rules */
}

.lumo.my-component {
 /* lumo token mapping */
}

.aura.my-component {
 /* aura token mapping */
}
```

One limitation to be aware of: this approach runs at attach time, so it doesn’t automatically react to live theme switching.

Example 3: Pivot Table (third-party legacy JS)

In this case, Pivot Table integrates an older jQuery-based library via a connector. A practical approach:

Detect the theme in connector before rendering heavy UI.
Add root class (aura or lumo).
Keep the library’s native CSS as the baseline.
Apply Vaadin-specific overrides for each theme.

For this kind of library, expect broader override surfaces than with modern Vaadin components.

Matching Vaadin overlay quality in third-party dialogs

When working with dialogs or popups from third-party libraries, simple color overrides aren’t enough.

To achieve visual parity with Vaadin components, you often need to align with the same underlying design rules:

Surface and text token mapping
Radius and border treatment
Elevation/shadow formulas
Focus-visible ring behavior

In some cases, this means porting the same “CSS math” used by Vaadin overlays, so that add-on dialogs blend with Aura and Lumo.

Vaadin 25.1+ recommendations

A couple of practical tips can save you time when working across Aura and Lumo.

Prefer Vaadin 25.1 or newer for Aura adaptation work. Earlier versions of Aura evolved quickly, especially around design tokens and defaults. That made styling harder to stabilize, as small updates could introduce visual inconsistencies. From 25.1 onward, the theme is more predictable, which makes a token-driven approach much easier to maintain.
Use unprefixed theme variants (25.1) where applicable. They help custom components apply variants that work across both Lumo and Aura, so you can define them once without branching styles or logic per theme and keep your component APIs simpler and more consistent.

Current framework gaps

While the current approach works well, a few gaps still lead to extra duplication in custom components:

Server-side API for active theme detection.
Shared JavaScript utility for theme detection usable outside Lit mixins.
Supported hook for dynamic theme switching in server-side and connector-based components.

Until more standardized support is available, lightweight, reusable helper utilities remain the most practical approach.

Optional acceleration for dual-theme CSS

For larger components or design systems, writing everything by hand can get repetitive. In these cases, a utility-first layering approach can help. Map utility classes to Aura/Lumo token-backed variables for color, radius, spacing, and shadows to reduce repetitive handcrafted CSS.

Practical checklist

When implementing or reviewing a component, this is a good sanity check:

Pick architecture (Lit, server-side DOM, extended Vaadin component, or connector).
Define internal --my-* tokens and consume only those in shared styles.
Add thin theme detection (data-application-theme or root class tagging).
Keep behavior and interaction logic theme-agnostic.
Add narrow Aura/Lumo overlays for visual differences.
Verify required, focus, invalid, readonly, disabled, and combined states.
Verify nested components and overlays for visual parity.
Re-test after Vaadin upgrades, especially around theme token changes.

Final takeaway

You do not need separate component implementations for Aura and Lumo. A token-driven styling model plus a small theme-selection layer is enough to make components feel native across both and scales across:

Lit web components
Server-side custom components
Connector-based third-party widgets
Extended Vaadin components with part-based styling

Once the foundation is in place, supporting both themes becomes a small, predictable layer of work—not a second implementation to maintain.

Have you tried this approach? We’d love to hear what worked (and what didn’t) in your setup. Happy coding!

Java Software Development in an AI-First World

fredu@vaadin.com (Fredrik Rönnlund) — Tue, 14 Apr 2026 06:31:24 GMT

Vaadin 2026 Community Survey: What Java Developers Told Us

Roman Kałkowski — Thu, 09 Apr 2026 10:22:27 GMT

We asked our customers and community how they use Vaadin,, what they value most, and what we need to do better. Here’s what we learned from the 2026 survey, even the parts that made us question what we thought we knew.

691

Respondents

98%

Use for Work

71%

Are Developers

Key Findings at a Nutshell

67% of people build internal applications, and Vaadin’s core is enterprise data-heavy apps
63% of people chose Vaadin because they already had a Java team. Existing skills drive adoption
40% faster time to market and 30% lower project costs reported by developers
83% of commercial users say that UI components are their top value driver
35% adopted Vaadin for legacy migration from Swing, JSF, GWT, and JavaFX
94% of commercial users would be disappointed if Vaadin disappeared
Top requests: more components, better documentation, React interoperability

Who Responded to the 2026 Survey

691 developers took the time to tell us about their experiences with Vaadin in our 2026 community survey. 98% of people use Vaadin for work, not side projects or experiments, and 71% are developers (the rest are architects, team leads, and managers).

They come from a lot of different types of organizations:

Company Size	Industry Focus
Startups (1–50)	Technology & Software
Mid-market (50–1,000)	Financial Services
Enterprise (1,000–10,000)	Manufacturing
Large Enterprise (10,000+)	Government & Public Sector

This isn’t a self-selected group of fans. There are a lot of different people building real enterprise Java web apps with real deadlines.

Internal Apps Are the Most Popular

67% of survey respondents build internal applications with Vaadin. External-facing and SaaS applications account for roughly 30%.

That makes sense with what we’ve always seen: Vaadin’s sweet spot is data-heavy business applications, like the admin panels, dashboards, and operational tools that keep business running. These are the kinds of apps where developer productivity is more important than making sure the design is perfect for every pixel, where security needs are non-negotiable, and where the app needs to be maintained for years, not months.

If you’re building internal tools for a Java team, you’re not alone.

Why Java Teams Choose Vaadin for Enterprise Web Apps

We wanted to know what made them choose Vaadin. Anyone who has worked with enterprise Java will not be surprised by the top answer:

63% said they chose Vaadin because they already had a Java team.

That’s the main point of the value proposition. If your team knows Java, Spring Boot, and Maven, building web UIs in the same language gets rid of the frontend bottleneck. You don't need a separate JavaScript team, no context-switching, and and you don't need two build pipelines.

But having some experience with Java was only part of the picture. The second most important factor was developer productivity and faster development speed. Teams consistently reported that consolidating frontend and backend into a single Java stack cuts down coordination overhead and speeds up delivery cycles. Survey respondents said they got their product to market 40% faster than before

The third big reason was the need for a modern, web-based UI without leaving the Java ecosystem. A lot of teams, especially those running desktop applications built on Swing or JavaFX, don't have to decide whether to move to the web; they just have to figure out how to do it without rewriting everything in a new language. Vaadin lets Java teams build modern, responsive web apps using the skills and infrastructure they already have.

It's interesting that components weren’t the main reason teams chose Vaadin — but they are a major part of the value once teams start building. More on that below.

40% Faster Time to Market, 30% Lower Costs

40%

Faster Time to Market

30%

Lower Project Costs

When developers switched to Vaadin, they said they could deliver their products to market 40% faster and save 30% on the total cost of the project.

Those are averages that people gave themselves, so use them as guides instead of strict benchmarks. But the pattern is consistent: teams that build their stack around Java ship faster and spend less time coordinating between the frontend and backend. You don't have to worry about designing a REST API layer, keeping a frontend build pipeline up to date, or handing off work between teams when your UI logic and business logic run on the same JVM.

What Commercial Users Care About Most

We asked people who have commercial plans, which features they think are the most useful. The results were obvious:

Feature	Very/Somewhat Valuable
UI Components	83%
Hotfixes	57%
Expert Chat	43%
Extended Maintenance	42%

Components are by far the most important thing that adds value. Access to hotfixes and direct expert support are the last two things that make up the top tier. This is the kind of safety net that businesses need when an application is critical to their business.

At the bottom of the list are Acceleration Kits (11%), legacy modernization features (12%), and Vaadin Copilot (14%). That means we need to work on making some of our newer features more useful to developers.

Open Source Is the Starting Point

61% of respondents use the open-source version of Vaadin. That's by design; Vaadin's core framework is fully open source, and we want developers to be able to work without hitting the paywall.

But here’s something we didn’t expect: in developer interviews conducted alongside this survey, many new users didn’t know that Vaadin is open source at all. We need to fix that gap in communication. If you’re evaluating Java web frameworks and open-source licensing matters to you, Vaadin Core is Apache 2.0 licensed.

Swing to Web Migration: Legacy Modernization Is Growing

35% of the companies that took part in the survey chose Vaadin specifically when migrating from legacy frameworks like Swing, JavaFX, JSF, and GWT.

We looked more closely at the group of people who said they keep Swing apps running:

78% said their legacy applications are very important to their business, with 64% calling them “critical”
37% consider their legacy applications permanent parts of their infrastructure, not temporary fixes that need to be replaced.
70% plan to run these apps for 5+ years or more, or even forever
The majority are still actively developing and adding features to their legacy codebases

This makes it clear that old Java apps aren't going away; they're just changing. And when organizations decide to modernize, Vaadin is the best way to do it. 35% of those with Swing applications are already migrating to Vaadin, and another 20% are still deciding.

Product-Market Fit: 94% Would Be Disappointed

We asked commercial users the classic question about product-market fit: “How disappointed would you be if you could no longer use Vaadin?”

94%

Would Be Disappointed

Not Disappointed

Only 6% claimed they would not be disappointed. 94% would be very or somewhat disappointed.

That’s a strong signal that for the teams using Vaadin commercially, it's not just a tool; it's the foundation of their infrastructure. Only 2% of commercial users don't have any active projects; the rest are both maintaining existing Vaadin apps and making new ones at the same time. It also means we have a duty to those teams to make sure that that releases happen on time, deliver long-term maintenance, and the roadmap is clear.

When compared, free-tier users have a higher rate of non-use (8%) and less active development, which suggests that a commercial relationship leads to a stronger commitment to the platform.

Where We’re Falling Short

Honest feedback is more valuable than compliments. Here’s what respondents told us needs to improve:

Components need to go further. The most common frustration was that Vaadin doesn’t have enough components, and existing ones need deeper functionality, like advanced grid features like column span and freeze options, more customization out of the box.

Documentation needs to be updated with new releases. Developers, especially those who are new to Vaadin, have a hard time finding up-to-date examples for newer versions. There is a specific gap in CSS styling documentation, even in older versions.

The most common reason why more organizations don't use it is that it doesn't work with other frontend technologies. The most common request was for React integration. Vaadin has a TypeScript and React path with the same Vaadin component library for teams that need flexibility on the front end, but not many people know about this option.

Developer availability is a real concern. Vaadin isn’t as widely known as some alternatives, and organizations report difficulty finding experienced developers.

We’re taking all of this seriously. Better components, better documents, and better interoperability are the things that make the framework more useful for more teams.

What the 2026 Survey Means for the Vaadin Community

This survey backs up what we hear from developers every day: Vaadin works best for Java teams building internal, data-heavy enterprise web apps, and those teams are very committed. The need for legacy modernization is growing, not shrinking. And the open-source core still is the starting point for most developers.

It also tells us where to put our attention: more UI components, better documentation for each release, and clearer messaging about what Vaadin is and how it fits into modern Java development.

If this is your first time using Vaadin, start a project and see how it works your team’s workflow. If you’re already building with Vaadin, thank you for being part of this survey — your feedback directly shapes what we build next.

Want to add something?

We want to hear from you, even if you didn't take this year's survey. You can share your thoughts in the Vaadin Forum, start a discussion on GitHub, or reach out to us. Let us know what's working, what's frustrating, and what you wish Vaadin did differently.

Every piece of feedback helps us prioritize what is most important to the people who are actually building with the framework.

Vaadin 24 Free Maintenance Ends June 16 — Choose Your Path Forward

Roman Kałkowski — Tue, 07 Apr 2026 13:37:45 GMT

Vaadin 25.1 is now available and makes for a strong, forward-looking upgrade. It is the first big release in the 25-series that makes it an attractive next step for teams building on the Vaadin platform.

With the June 16, 2026 maintenance deadline for Vaadin 24 approaching, this is a good moment to explore your options and plan ahead. Upgrading to Vaadin 25.1 lets you take advantage of the latest enhancements and stay on a fully supported path.

This post covers what the maintenance transition means in practice, what makes Vaadin 25.1 a compelling upgrade target, and what to do if upgrading right now is not realistic for your team.

What "Maintenance Mode" Means for Your V24 Application

Vaadin maintenance helps you deliver long-lasting, reliable applications by keeping your software up to date with critical fixes and improvements. From security patches and browser compatibility updates to framework and integration enhancements, staying on a maintained version ensures your app remains secure, stable, and dependable over time.

During the free maintenance window (until June 16, 2026), security patches and critical bug fixes are available for the latest Vaadin 24 minor version. If your application is pinned to an older minor version (for example, 24.3 or 24.5), that version is already past its free support window.

After June 16, free maintenance ends. Applications on Vaadin 24 will continue to function normally, but security patches, resolutions for browser compatibility issues, and bug fixes will no longer be provided.

If your team needs more time beyond June, our recommendation is to plan your upgrade now or get Extended Maintenance (available through the Enterprise plan) covers Vaadin 24 — including individual minor versions — with security patches and browser compatibility updates for up to 15 years. More on that in the maintenance policy overview.

What's New in Vaadin 25.1

Here are the key areas worth knowing about.

Simpler Theming and Styling

Theming in Vaadin 25 is less framework configuration and more plain CSS. Themes are now just stylesheets, which means you can dynamically switch between them at runtime. This is useful for light/dark mode, per-user preferences, or multi-tenant branding.

Vaadin 25 also introduces Aura, a new modern theme built on stronger component base styles. The previous theme engine, Lumo, however also remains available. The Material theme has been removed — applications using it need to migrate to Lumo, Aura, or a custom approach built on the new base styles.

Leaner and Faster

A production-bundled Vaadin 25 application has roughly 30% fewer transitive dependencies by default.This is a 22 MB reduction compared to V24. Dev-mode server startup is over 50% faster, and deployment is about 27% quicker. The framework removed several external dependencies and leveraged APIs available in newer Java versions instead.

Simplified Build System

Production builds no longer depend on a dedicated Maven profile. Both Maven and Gradle now produce a production artifact by default, and development builds are used only when running inside an IDE. CI pipelines and buildpacks behave like a standard Java build.

Updated Technology Baseline

This is where the upgrade effort primarily sits for most teams:

Requirement	Vaadin 24	Vaadin 25
Java	17+	21+
Spring Boot	3.x	4
Spring Framework	6	7
Jakarta EE	10	11
Servlet	6.0	6.1
Node.js	20+	24+
Maven	3.5+	3.8+

View full Vaadin’s version comparison table

Vaadin 25 also upgrades from Jackson 2 to Jackson 3, which may affect applications with custom serialization logic. And Hilla is now an opt-in dependency — if your project uses Hilla or React-based views, add hilla-spring-boot-starter alongside vaadin-spring-boot-starter.

If your project is already on Java 21 and can move to Spring Boot 4, the baseline shift is straightforward. If you are locked to Java 17 or Spring Boot 3, assess those dependencies first: they define the scope of your upgrade.

Vaadin 24 vs. Vaadin 25: Choosing the Right Timing

For most teams, Vaadin 25.1 is the recommended upgrade target — it is stable, feature-rich, and the natural adoption point for anyone who was waiting for the platform to mature past the initial 25.0 release. But upgrading is not the only valid path forward.

That said, the right timing depends on your situation:

Upgrade now if your project is on Java 21 and Spring Boot 3.x (or ready to move to Spring Boot 4), you are not using the Material theme, and your third-party dependencies are compatible with the new baselines. We recommend first addressing any deprecation warnings on the latest Vaadin 24, then updating the Vaadin version in pom.xml. Any remaining deprecation warnings after upgrading are not urgent — they will most likely not require immediate attention before Vaadin 26.

Consider Extended Maintenance if you cannot realistically upgrade before June 16, 2026 — Extended Maintenance is not a consolation prize. It is a legitimate path that provides up to 15 years of security patches, browser compatibility updates, and critical bug fixes for your specific V24 version. It keeps your V24 application secure and supported while you plan your upgrade on your own timeline. It covers both V24 major and individual minor versions (24.0 through 24.9), so even teams pinned to an older minor release are fully supported. Extended Maintenance is included in the Enterprise plan and available as a standalone service. Learn more at vaadin.com/maintenance.

Before You Start: A Practical Checklist

Here is a quick checklist to help scope the effort before you commit to a sprint:

Read the upgrade guide. The official V24 → V25 upgrade instructions walk through the specific steps and breaking changes.
Start a test branch. The fastest way to estimate effort is to bump the version and see what breaks. Many teams find the upgrade smoother than expected.
Check your Java version. Vaadin 25 requires Java 21. If you are on Java 17, this is likely your first upgrade step.
Check your Spring Boot version. Vaadin 25 requires Spring Boot 4 / Spring Framework 7. Review your Spring dependencies and any libraries that may be pinned to Spring Boot 3.x.
Review your security configuration. Spring Security 7 introduces breaking changes, and the deprecated VaadinWebSecurity patterns from V24 have been removed. If your application has custom security configuration, review this early. The new patterns are supported in Spring Security 6 and the latest Vaadin 24 versions, so it is recommended to make this change as a separate step even before the main upgrade.
Audit your theme. If you are using the Material theme, plan for a styling migration. If you are on Lumo, the transition is smoother — but review any custom theme configuration for the new stylesheet-based approach.
Review third-party add-ons. Check that any Vaadin add-ons or third-party components you use have published V25-compatible versions. The Vaadin Directory is a good place to verify.
Check your Node.js version. The frontend build now requires Node.js 24+. Note that if a compatible version is not found globally, Vaadin will automatically download and install it for you into your ~/.vaadin/ directory.
Update your test setup. Spring Boot 4 defaults to JUnit 6 (JUnit Platform). If you have JUnit 4 tests using UIUnit4Test or TestBenchTestCase, they will not be detected without adding the JUnit Vintage Engine dependency. Also note that ComponentTester.click() in UI Unit has a new signature — tests using AnchorTester or RouterLinkTester need to change to the navigate() method.
Check Jackson usage. Vaadin handles the Jackson 2 to Jackson 3 migration automatically in most cases. If your application has custom serializers, deserializers, or Jackson annotations, review the Jackson 3 migration guide.
Migrate Elemental JSON usage. If you have custom components that use the Elemental JSON library for browser communication, these need to be changed to use beans, lists, maps, and other standard Java collections instead.
Re-add dev tools explicitly. The vaadin-dev module is no longer included as a transitive dependency. Always include vaadin-dev as an optional dependency so that it is used in development but not included in production builds.

Resources

Vaadin 25.0 release post — detailed walkthrough of all changes
Upgrade guide — step-by-step upgrade instructions
Versions of Vaadin comparison table — side-by-side technical comparison across Vaadin versions
Extended maintenance policy — long-term security and stability for V24
Faster and Slimmer Vaadin 25 — performance benchmarks and dependency analysis
An Unexpectedly Hassle-Free Upgrade — a community developer's real-world V25 upgrade experience
Vaadin 25.1 release post — free Copilot, production-ready Signals, and more

Need Help Planning Your Upgrade?

If your team wants a second opinion on your path forward — whether you are upgrading to Vaadin 25.1 or evaluating Extended Maintenance — we are happy to help. Book a 30-minute consultation to review your setup and get a realistic assessment of both options.

Vaadin 24 has served the community well, and Vaadin 25.1 builds on that foundation with a cleaner, faster, more standards-aligned platform. You have two equally valid paths:

Upgrade to Vaadin 25.1 now, while free maintenance is still active and the transition is straightforward.
Secure Extended Maintenance and upgrade when your team is ready.

The June 16 deadline is approaching, but whichever path you choose, the goal is the same: no surprises, no scrambling, just a clear path forward.

Vaadin.com Blog

How South Tyrol modernized government software with Java and Vaadin

Supporting the digital infrastructure of 116 municipalities

Building a modern eGovernment platform with a seven-person team

Why the team chose full stack Java and Vaadin

Modernizing one of the region’s most complex public-sector systems

From legacy monolith to modern public platform

Building public-sector software designed for reuse

Planning a public-sector modernization project?

A more Playwright-like API for Vaadin browserless tests

A short example

Contexts

Multi-user is just two windows

No mandated superclass

Locators

Filter chain reads like a sentence

The escape hatch is one call away

Why the wrap step matters

A small end-to-end

Write your own locators - scale up with page objects

Why we think this is worth defaulting to

Status and where to follow along

How To Ensure Serializable Sessions in Vaadin 25 Applications

Why This Matters

The Core Rule

Pattern 1: Make UI Graph Objects Serializable

Pattern 2: Mark Runtime-Only Dependencies as transient

Pattern 3: Rehydrate transient Fields Lazily

Pattern 4: Use Serializable Callback Types

Pattern 5: Clean Up on Detach

Pattern 6: Prefer Explicit Listener Lifecycle

Pattern 7: Enable Kubernetes Kit Session Replication Debug Tool

7.1 Enable in application properties

7.2 Enable extended Java serialization diagnostics

7.3 Optional explicit registration (as in this demo)

7.4 Reading results

Pattern 8: Debug Session Sizes During Serialization

8.1 Enable debug logging

8.2 Read size from serializer log lines

8.3 Practical usage

Pattern 9: Wrap Naturally Non-Serializable Components

Spreadsheet example (Apache POI workbook state)

Use Linters as an Early Warning System

The Most Important Verification: Serialize the View Graph in Tests

What Level of Coverage Is Enough?

A Quick Checklist You Can Use Today

Final Takeaway

How Eduten Built a High-Usage Learning Platform with Vaadin

The Problem

The Solution

The Result

Looking ahead

Have questions about building at scale with Vaadin?

Printing and Saving PDFs From Web Apps

1. Just print and style with CSS

1.b Print and use JS hook for preparations

2. Construct a print-optimized page

3. Generate a PDF

4. Skip the OS print dialog entirely

4a. Talk to the printer from the browser (Web Bluetooth)

4b. Print from the server (or a custom service)

Picking an approach

The Definitive Guide to Modernizing Java Swing Applications in 2026

Table of Contents

Why Swing Applications Need Modernization Now

The Talent Gap Is Already Here

User Experience Expectations Have Shifted Permanently

The Operational Overhead of Desktop Swing Applications

Security Risks Are Expanding, Not Shrinking

Accessibility and Regulatory Compliance Are No Longer Optional

The Cost of Waiting Is Compounding

The Three Modernization Approaches

Approach 1: Lift-and-Shift (Run Swing in the Browser)

Approach 2: Incremental Migration (Screen-by-Screen Modernization)

Approach 3: Full Rewrite

Decision Framework: Choosing Your Approach

Factor 1: Application Size and Complexity

Factor 2: Quality of Existing Business Logic

Factor 3: Time to Value

Factor 4: Team Composition