Docs

Docs

Reference

Public API summary, lifecycle hooks, and the recommended sample project.

This page summarizes the public Java API surface of SwingBridge and points at the skeleton starter project.

What Happens Under the Hood

Once you’ve set up your [classname]`SwingBridge` subclass (or instance), the framework handles:

  • Launching your Swing application in the background when the component attaches.

  • Capturing the UI as images and streaming the changed regions to the browser.

  • Routing user interactions — clicks, keyboard input, window resizing — back into the AWT event queue.

  • Managing dialogs, popups, and tooltips that your Swing application creates.

  • Updating the display continuously so users see a live view of your application.

Every browser session runs the Swing application inside its own isolated [classname]`AppContext`, so two users do not share static state, focus, clipboard, or drag-and-drop status.

SwingBridge Component

The `[classname]`SwingBridge class is the entry point. It is a Vaadin Flow `[classname]`Div that, on attach, launches the Swing application and renders it into the page.

Constructors

Source code
Java
new SwingBridge(String mainClassFQN);
new SwingBridge(String mainClassFQN, String[] args);
new SwingBridge(String mainClassFQN, Supplier<URLClassLoader> classLoaderSupplier);

The first form uses the default classloader supplier (loads JARs from the applibs/ directory). The second forwards the given arguments to the Swing application’s main method. The third hands full control of classloader construction to the caller — pair it with [classname]`SwingBridgeRunner`’s helpers to load JARs from a `swing-app-jar-list.conf file or a custom location.

Lifecycle Hooks

[classname]`SwingBridge` exposes two protected hooks. Override them in a subclass to run custom code before or after the Swing application is wired into the view.

Hook When it runs

[methodname]`beforeInit(Component component)`

After the Swing application has launched and produced a visible [classname]`JFrame`, but before SwingBridge wires that frame into its canvas. Useful for last-minute configuration of the Swing component itself (sizing, native look-and-feel tweaks).

[methodname]`afterInit(Component component)`

After SwingBridge has wired the frame into its canvas and frame updates are ready to flow. Useful for hooking up listeners on the Swing component or signalling readiness to the rest of the Vaadin view.

A custom classloader supplier is contributed via [methodname]`createClassLoaderSupplier()`, which subclasses also override (see Constructor Variants).

SwingBridgeRunner Helpers

[classname]`SwingBridgeRunner` is a static utility used by the component itself, but several of its methods are public and useful when you build a custom classloader supplier.

Method Use

[methodname]`createSession(String mainClassFQN)`

Create a `[classname]`SwingBridgeSession that ties the Vaadin session to a specific main class. Pass it to `[methodname]`runSwingApp(…​).

[methodname]`runSwingApp(SwingBridgeSession, …)`

Launch the Swing application in an isolated `[classname]`AppContext. Returns a `[classname]`CompletableFuture<JFrame> that resolves when the first window appears (or completes exceptionally on launch failure).

[methodname]`loadSwingAppJarList()`

Read a swing-app-jar-list.conf from the classpath root and return the JAR paths it lists. Combine with [methodname]`createClassLoader(…​)`.

[methodname]`loadJarsFromDirectory()`

Read every .jar in the configured applibs directory.

[methodname]`createClassLoader(List<Path> jars, ClassLoader parent)`

Build a [classname]`URLClassLoader` from the supplied JAR paths.

Sample Project

The skeleton starter is the recommended starting point. It is a working SwingBridge project — Maven configuration, JVM flags, and a Vaadin view wired up — that you can clone and adapt to your own Swing application by replacing the JARs in applibs/. See Getting Started for the walkthrough.

Next Steps

Updated –