A small library that lets you embed Vaadin Flow in asingle executable JAR — spun up against embedded Jetty with a minimal API. No Spring, no application server, no XML. Just a couple of static method calls.

Why this exists

Vaadin’s default packaging path leans on Spring Boot or a servlet container running a WAR. For tiny tools, internal dashboards, or one-shot utilities that’s overkill — you want ajava -jar foo.jar and be done.

The catch: embedded Jetty’s annotation scanner only walks JARs andWEB-INF/classes. When the app runs from an IDE ormvn exec:java, your@Route classes live in plain classpath directories that Jetty’s scanner ignores. Vaadin’sRouteRegistryInitializer then sees zero routes and your “Hello World” 404s.

Nano Vaadin Jetty solves that without forcing you into framework-land.

The whole API in three calls

importcom.svenruppert.vaadin.nano.CoreUIServiceJava;// 1. Plain start — caller wires routes elsewhereServerserver=CoreUIServiceJava.startServer("127.0.0.1",8080).getOrThrow();// 2. Explicit routes — registered race-free before the first requestServerserver=CoreUIServiceJava.startServer("127.0.0.1",8080,List.of(MyView.class,AdminView.class)).getOrThrow();// 3. Scanned routes — classgraph walks given packages on the runtime classpathServerserver=CoreUIServiceJava.startServer("127.0.0.1",8080,CoreUIServiceJava.scanForRoutes("com.example.views","com.example.admin")).getOrThrow();

That’s the surface. Everything else is config-as-code.

First-class failure handling

startServer(...) returns aResult<Server, Exception> (fromfunctional-reactive), so a port-bind failure or missing config is a first-class return value rather than a thrown checked exception:

CoreUIServiceJava.startServer("127.0.0.1",8080).peek(srv->logger().info("listening on {}",srv.getURI())).peekFailure(err->logger().error("startup failed",err));

Fail-fast bundle probe

The library probes the classpath forMETA-INF/VAADIN/webapp/index.htmlbefore booting Jetty. If the frontend bundle is missing,startServer(...) short-circuits to aResult.failure(IllegalStateException) with a message naming the missing path and pointing at the right Maven goal — you don’t have to debug Vaadin’s runtimeHTTP 500 / Unable to find index.html mystery anymore.

When to use it

✅ Internal tooling, ops dashboards, one-shot utilities ✅ Demos where Spring Boot is overkill ✅ Anything you want to ship as a singlejava -jar binary ✅ Embedded scenarios (Raspberry Pi, IoT gateways)

❌ Production apps where you already have Spring/Quarkus in the stack — use those ❌ When you need a full WAR deployment lifecycle

Status

Active. Updated regularly as Vaadin Flow and Jetty release new versions. Currently trackingVaadin Flow on Jetty 12 (EE11) with Java 26.

License isEUPL-1.2 — copyleft-style, EU-approved equivalent to LGPL.

A pure-JDK URL shortener built as a learning vehicle for theAdvent Calendar 2025 series. Every step is documented in a blog post — 14 parts covering everything from the route registry and persistence layer to Server-Sent Events for live click tracking and a Vaadin Flow UI.

What it covers

• No Spring, no JPA, no magic. Pure Core Java + Vaadin Flow.
• Per-step incremental builds. Each post in the series adds one feature you can run, break, and learn from in isolation.
• REST + UI in one binary. A REST endpoint creates short URLs; the Vaadin Flow admin UI lists clicks live via SSE.
• Production-style concerns covered too — auth, observability, persistence, rate-limiting — but always from the JDK side, not framework-side.

Why a separate project site?

The shortener has its own domain (url.svenruppert.com) because it doubles as the live demo — every shortened link runs through this exact codebase. Eat your own dogfood, etc.

The build details, architecture decisions and lessons-learned all live on theseries page on this site.

A small library of building blocks fortype-safe generic programming in Java. Born out of the realisation that most “generic” Java code drops toObject and casts back — and that this is largely fixable by leaning harder on the type system rather than around it.

What’s in the box

• Type witnesses for runtime generic introspection (working around erasure)
• Builder patterns that retain compile-time type information
• Composition helpers for functions, predicates and consumers
• Result / Either style utilities that compose withOptional andCompletableFuture

When it helps

• Library code that needs to expose generic APIs without forcing callers to cast
• Domain models where aMap<String, Object> would technically work but losing type info costs maintainability
• Glue code between strongly-typed Java and weakly-typed external sources (JSON, configs)

Documentation, releases and discussion live onGitHub.