Mirror of the GitHub repository at https://github.com/junit-team/junit-framework/ (PRs welcome on Codeberg!)

Many example projects overload the starting point by covering too many topics at once. Routing, data access, security, forms, theme customisations, and other integrations will then be presented in a single demo. This makes it more difficult for readers to recognise the project's actual structure. This project takes a different approach. The focus is on a compact framework comprising AppShell, MainLayout, several views, a small service, its own theme, and prepared internationalisation.

Modern web applications are rarely used only by users with the same language. Even internal tools often reach international teams or are used in different countries. A multilingual user interface is therefore not a luxury feature, but an important part of the user experience. The open-source project URL-Shortener also benefits from a clear internationalisation strategy. The application is intended for developers, administrators, and other users who want to manage, analyse, or distribute links.

Vaadin Flow enables the development of complete web applications exclusively in Java. Components, layouts, navigation, and even complex UI structures can be modelled on the server side without working directly with HTML or JavaScript. This approach is one of the main reasons why Vaadin is especially popular in Java-centric projects. However, as a project grows in size, a typical problem arises: styling is often done directly in Java code.

The starting point for this article was not a strategic architecture workshop or a long-term planned migration path, but a comparatively unspectacular step: updating the version numbers in the existing project. As part of further developing my URL shortener project, a regular dependency update was due anyway. Vaadin 25 (was already available at that time, so it made sense to proceed.

Why an import needs a UI at all Import functions are often treated as purely technical details in applications. Data is read in, processed and then made available – ideally without further interaction. In practice, however, an import is rarely an invisible process. It marks a transition between existing system states, between old and new data, between trust and control. This is exactly where the need for a user interface arises.

Export functions are often seen as a purely technical side task: one button, one download, done. In a Vaadin-based application, however, it quickly becomes apparent that exporting is much more than writing data to a file. It is a direct extension of the UI state, an infrastructural contract between frontend and backend, and a decisive factor for maintainability and predictability.

What has happened so far In the first part, the focus was deliberately on the user interface's structural realignment. The previously grown, increasingly monolithic OverviewView was analysed and specifically streamlined by outsourcing key functional areas to independent UI components. With the introduction of the BulkActionsBar and the SearchBar, clearly defined building blocks were created, each assuming a specific responsibility and freeing the view from operational details.

Today marks a crucial step in the evolution of the URL shortener's user interface. After the focus in the past few days was mainly on functional enhancements – from filter and search functions to bulk operations – this day is dedicated to a structural fine-tuning: the refactoring of central UI components. This refactoring not only serves to clean up the code but also creates a clear, modular basis for future extensions as well as a significantly improved developer experience.

What has happened so far? In the first part of this article, the new active/inactive model for shortlinks was introduced and anchored at the architectural level. Based on the technical rationale, it was shown that a pure expiration date is insufficient for modern use cases and that an explicit activity status is required. Based on this, the technical foundations were laid: the core domain model was extended with an…

Why an active/inactive model for shortlinks? For many users – especially those who work in the field of software development – shortlinks are much more than simple URL shorteners. They act as flexible routing mechanisms for campaigns, feature controls, test scenarios, and internal tools. The requirements for transparency, controllability and clean lifecycle management are correspondingly high. The URL shortener receives an active/inactive model that directly supports these claims.

What has happened so far? In the first part of "Basic Login Solution", the foundation for a deliberately simple yet structurally clean admin login was laid. The starting point was the realisation that even a technically lean URL shortener requires a clear separation between public-facing functions and administrative operations. The goal was not complete user management, but rather a minimal access barrier that integrates seamlessly with the existing Java and Vaadin architectures.

Introduction The administration interface of a URL shortener is a sensitive area where short links can be changed, removed, or assigned expiration dates. Although the system is often operated on an internal server or in a private environment, protecting this management interface remains a fundamental security concern. Accidental access by unauthorised users can not only lead to incorrect forwarding or data loss, but also undermine trust in the overall system.

What has happened so far... In the previous part, the URL shortener overview was significantly expanded. The starting point was the realisation that the last UI was heavily optimised for single operations and thus quickly reached its limits as soon as larger volumes of shortlinks needed to be managed. To resolve this bottleneck, the grid was consistently switched to multiple selection, creating the technical basis for actual mass operations.

The next stage of the Advent calendar focuses on further development, which becomes immediately noticeable once more shortlinks are used. The previous interaction patterns in the Overview view were geared toward individual operations and yielded only limited efficiency gains when processing many objects simultaneously. Today, this paradigm is being deliberately broken up and replaced by an interplay of new UI concepts that, for the first time, enable true multi-operation, context-sensitive work, and a much more stringent user interface.

After the first part explained the conceptual basics and the new interactions among global search, search scopes, and advanced filters, the second part focuses on the technical mechanisms that enable these interactions. It is only the revised refresh architecture – above all the interaction of safeRefresh() and RefreshGuard – that ensures that the OverviewView remains calm, deterministic and predictable despite numerous potential triggers.

Since its inception, the URL shortener's continuous development has focused on two core goals: a robust technical foundation without external frameworks and a modern, productive user interface that is both intuitive and efficient for power users. As part of the current development stage, an essential UI module has been revised – the OverviewView, i.e. the view in which users search, filter and manage all saved shortenings.

Today's update introduces another practical development step for the URL shortener. After the last few days were dedicated to UI refinement and the better structuring of detailed dialogues and form logic, the focus is now on an aspect that plays a significant role in the everyday life of many users: the flexible management of multiple aliases per target URL. You can find the source code for this development status on GitHub under…

Introduction: More convenience for users With today's development milestone for the URL Shortener project, a crucial improvement has been achieved, significantly enhancing the user experience. Up to this point, working with short URLs was functional, but in many ways it was still linear: each destination URL was assigned exactly one alias. This meant users had to create a new short URL for each context or campaign, even when the destination was identical.

The current UI from the user's point of view On the first call, the user lands in the overview. The site is built on a Vaadin grid, whose header contains a search bar, paging controls, and a small settings button with a gear icon. The most essential flow begins with the table displaying immediately understandable columns: the shortcode as a clearly typographically separated monospace value with copy action, the original URL as a clickable link, a creation time in local format, and an expiration badge that visually communicates semantic states such as "Expired", "Today" or "in n days" via theme colours.

Server-Side Extension: PreferencesHandler and REST Interfaces The server-side extension for dynamic column visibility follows the same design logic as the UI: simplicity, clear accountability, and a precise data flow. While the OverviewView and the ColumnVisibilityDialog form the interface for the interaction, several specialized REST handlers handle the processing and persistence of the user settings. Their job is to process incoming JSON requests, validate them, translate them into domain operations, and return or store the current state.

From observer to designer: User control at a glance With the fourth day of the Advent calendar, the perspective on the application changes fundamentally. While in the previous expansion stages users reacted primarily to prepared structures, an element of active design is now being added. The "Overview" has so far been a central mirror of the system state: It showed all saved short links, allowed them to be filtered and provided an in-depth insight into individual objects with the detailed dialog.

Client contract from a UI perspective In this project, the user interface not only serves as a graphical layer on top of the backend, but is also part of the overall contract between the user, the client, and the server. This part focuses on the data flow from the UI's perspective: how inputs are translated into structured requests, how the client forwards them, and what feedback the user interface processes.

Classification and objectives from a UI perspective Today's Advent Calendar Day focuses specifically on the interaction level prepared in the previous parts. While the basic structure of the user interface and the layout were defined at the beginning, and the interactive table view with sorting, filtering and dynamic actions was subsequently established, it is now a matter of making the transition from overview to detailed observation consistent.

Today, we will finally integrate the StoreIndicator into the UI. Vaadin integration: live status of the store Implementation of the StoreIndicator Refactoring inside – The MappingCreator as a central logic. EclipseStore – The Persistent Foundation Additional improvements in the core Before & After – Impact on the developer experience The source code for this version can be found on GitHub at…

Visible change: When the UI shows the memory state With the end of the last day of the Advent calendar, our URL shortener was fully functional: the admin interface could filter, sort, and display data page by page – performant, cleanly typed, and fully implemented in Core Java. But behind this surface lurked an invisible problem: All data existed only in memory.

In the previous part, we looked at the implementation on the server side. This part is now about the illustration on the user page. The source code for the initial state can be found on GitHub under . The following screenshot shows this state of development. The focus of this Advent calendar day is on the introduction of targeted…

With the Vaadin interface described in [Part III], our URL shortener has a fully functional administration console available for the first time. It allows viewing existing short links in tabular form and managing them manually. But after just a few dozen entries, a clear limit becomes apparent: displaying all saved mappings is neither performant nor user-friendly. An efficient shortener must be able to scale – not only when generating, but also when searching through its data.

December 2025 is all about a project that has grown steadily in recent months: the Java-based URL Shortener, an open-source project implemented entirely with Core Java, Jetty, and Vaadin Flow. The Advent calendar accompanies users every day with a new feature, a technical deep dive, or an architectural improvement – from the basic data structure and REST handlers to UI components and security aspects.

YouTube video by Sven Ruppert - german

Chapter 1 – Introduction 1.1 Motivation: Real-time communication without polling In modern applications, it is often necessary to provide new information to the client as quickly as possible. Classic polling, i.e. regularly querying a REST endpoint, is inefficient: it generates unnecessary network traffic and puts a load on both server and client, as requests continue even when there is no new data.

Reactive streams address a fundamental problem of modern systems: Producers (sensors, services, user events) deliver data at an unpredictable rate, while consumers (persistence, UI, analytics) can only process data at a limited speed. Without a flow control model , backlogs, storage pressure, and ultimately outages occur. With Java, java.util.concurrent.Flow provides a minimalist API that standardises this problem: Publisher → Processor → Subscriber,

1. Introduction 1.1 Motivation: Event-driven updating without polling In classic web applications, the pull principle still dominates: Clients repeatedly make requests to the server to detect changes. This polling is simple, but it leads to unnecessary load on the server and network side, especially if the data stock changes only sporadically. Server-Sent Events (SSE) is a standardised procedure that allows the server to signal changes to connected clients actively.

Password security is an often underestimated but critical topic in software development. Databases containing millions of user logins are repeatedly compromised – and shockingly, often, it tu…

1. Introduction and objectives The first two parts of this series established the theoretical and practical foundations of a URL shortener in pure Java. We discussed the semantic classification of …

YouTube video by Outdoor Skills

1. Introduction Why REST integration in Vaadin applications should not be an afterthought In modern web applications, communication with external services is no longer a special function, but an in…

YouTube video by Sven Ruppert - german

A URL shortener seems harmless – but if implemented incorrectly, it opens the door to phishing, enumeration, and data leakage. In this first part, I’ll explore the theoretical and security-re…

Ein tiefer Blick in Java’s HashMap-Fallen – visuell demonstriert mit Vaadin Flow Die stille Gefahr in der Standardbibliothek…

A deep look into Java’s HashMap traps – visually demonstrated with Vaadin Flow. The silent danger in the standard library The use of HashMap and HashSet is a common practice in everyday Java develo…

Vaadin Flow ist ein leistungsstarkes Framework zur Erstellung moderner Webanwendungen in Java, bei denen die gesamte UI-Logik serverseitig…

Vaadin Flow is a robust framework for building modern web applications in Java, where all UI logic is implemented on the server side. In this blog post, we’ll make a simple file management ap…

JugSaxony Webseite