Same application, two runtimes: how Swing and JavaScript cooperate in one user journey
A Java Swing application from 2004 and a modern JavaScript application do not seem to have much in common. One thinks in JFrame, JTable and Java2D; the other in components, browser events and JSON. Yet they can appear in the same window, answer the same user and carry out the same task. This article explains how that works, and what stays true underneath.
Two Runtimes, One Session
Swing and JavaScript do not share a process or heap. They cooperate across a distributed session made of three parts: a browser client, a Webswing server and an application JVM.
The JavaScript runs in the browser client. The Swing program runs in the application JVM on the server. Webswing links the two into a single user session, so they share a user journey and an interface, but not memory. The authoritative state of the interface, what is selected, what is open, what is half-edited, along with the domain objects and business rules, stays in the running Java application. The browser client is a display and input surface for a program that executes elsewhere.
How Rendering and Input Travel
Input and rendering cross the network as discrete events and drawing updates, not as a video feed.
Swing is portable because it never draws to the operating system directly. Oracle describes java.awt.Toolkit as the layer that binds platform-independent AWT classes to their platform-specific implementations. [3] Webswing integrates at this platform boundary, so ordinary Swing and AWT behaviour is represented through a browser client, and the program keeps creating ordinary components and handling ordinary AWT events.
The interaction loop is short:
1. The browser client captures a key press or click.
2. The event travels to the server over a persistent WebSocket connection, rather than a new HTTP request per click. [4]
3. The application JVM processes the event.
4. The affected region of the interface is repainted.
5. Webswing sends the resulting drawing updates back.
6. The browser client replays them on HTML5 Canvas.
The browser renders the interface of the server-side program. According to the Webswing 26.1 documentation, DirectDraw sends Java2D drawing instructions that the browser replays on Canvas, caching repeated resources rather than streaming screenshots. [5] DirectDraw therefore transmits drawing operations rather than converting Swing components into DOM elements, and the result is neither a DOM conversion nor a conventional video stream.
The Peripheral Problem
Moving a desktop application to a server separates it from the user’s local printer, clipboard and filesystem.
The consequences show up as simple questions. Whose printer does File then Print use? Whose clipboard receives copied data? Which filesystem appears in a file chooser? The literal answer, the server’s, would be useless, so a server-hosted Swing application has to reconnect the running program to the devices beside the user. Three cases carry most of the weight.
Printing. Standard Java printing can be converted to a PDF delivered through the browser, which is the default behaviour. [6] Direct printing to a local printer is possible only in controlled setups, such as a custom print dialog or kiosk-mode configuration. Silent local printing is not a universal browser capability, and it should not be presented as one.
Clipboard. Clipboard integration can bridge text, HTML, images and files between the Java program and the browser client. [7] Browser security rules then apply: the Clipboard API requires a secure context and the relevant permissions. Some clipboard operations also require explicit user interaction, with details varying between browsers. [8] It is governed by more than HTTPS alone.
Files and desktop actions. A JFileChooser is mapped to browser upload, download or delete rather than a browse of the server filesystem. [9] Actions from java.awt.Desktop, such as opening a link or a document, are translated into appropriate browser-side actions.
Desktop assumptions about nearby devices are often harder to preserve than the screen itself.
A Seam for New Web Work
JsLink provides a controlled boundary between the Java application and browser code.
Michael Feathers calls a controlled point of intervention a seam: a place where behaviour can change without rewriting the surrounding system. [10] The Java-to-JavaScript boundary can serve as such a seam, provided it stays narrow and deliberate. Through it, JavaScript may call into Java for targeted integration, and Java may signal browser components in return.
New capabilities should not normally remote-control the whole existing interface. Where a business capability is reusable, the better move is to expose it behind a service that both the old interface and new web code can call, rather than driving the old screens from JavaScript. A stable integration boundary matters in a world where the next interface technology may change before the underlying business capability does.
What This Preserves
Running the program in place preserves its object graph, its business logic and the Java runtime it already uses.
In a mature desktop application, the interface, the business rules and much of the state share one JVM heap. A listener calls a service, the service updates an in-memory model, and the model refreshes a table, often without any HTTP or JSON. That coupling is one reason such systems resist a clean rewrite, and browser delivery does not sever it. The program keeps running with its object graph intact, while the browser client becomes a remote surface for it.
The runtime is part of what is preserved. At the time of writing, Webswing 26.1 supports applications running on Java 8, 11, 17, 21 and 25, and much of this behaviour has been built up gradually across releases since the project started in 2012. [11][12] Keeping the program where it already lives avoids a forced runtime upgrade. A rewrite, by contrast, may require upgrades elsewhere in the stack, including the Java runtime, libraries, build system and deployment model, which may be desirable but should be an explicit decision rather than an accidental prerequisite.
What It Costs
A live desktop session consumes server resources differently from a stateless web request. This makes the architecture closer to running many interactive application sessions than serving identical stateless pages.
Every interaction makes a round trip, so responsiveness depends on network latency. Each session is a running application instance rather than a short-lived request, which turns session management, capacity planning and observability into real concerns. Webswing’s hardware guidance recommends measuring multiple representative sessions rather than sizing from a generic per-user number alone. [13] A sizing diagram can provide a starting hypothesis, but production capacity should be based on measured representative sessions.
Takeaway
The monolith did not become JavaScript. Its components, rules and state still run in a server-side JVM. The browser captures input, renders the interface and provides a place for new web components to attach. Two runtimes remain technically separate, but to the user they form one application and one continuous journey.
References
1. Webswing. “Overview.” Webswing Documentation, version 26.1. https://www.webswing.org/docs/26.1/overview
2. Webswing. “Developer’s Guide.” Webswing Documentation, version 26.1. https://www.webswing.org/docs/26.1/devguide
3. Oracle. “Class Toolkit (java.awt.Toolkit).” Java SE API Documentation. https://docs.oracle.com/javase/8/docs/api/java/awt/Toolkit.html
4. MDN Web Docs. “The WebSocket API (WebSockets).” https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
5. Webswing. “Swing Config” (DirectDraw). Webswing Documentation, version 26.1. https://www.webswing.org/docs/26.1/reference/swing-config
6. Webswing. “Printing.” Webswing Documentation, version 26.1. https://www.webswing.org/docs/26.1/integrate/printing
7. Webswing. “Clipboard.” Webswing Documentation, version 26.1. https://www.webswing.org/docs/26.1/integrate/clipboard
8. MDN Web Docs. “Clipboard API” (security constraints). https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API
9. Webswing. “File Handling.” Webswing Documentation, version 26.1. https://www.webswing.org/docs/26.1/integrate/files
10. Michael C. Feathers. “Working Effectively with Legacy Code.” Prentice Hall, 2004 (the “seam” concept).
11. Webswing. “FAQ” (supported Java versions). https://www.webswing.org/en/faq
12. Webswing. “Company” (history since 2012). https://www.webswing.org/en/company
13. Webswing. “Hardware Requirements.” Webswing Documentation, version 26.1. https://www.webswing.org/docs/26.1/install/hwreq
arrow_back_ios
