Why “migrate to the cloud” and “rewrite from scratch” are two different projects that got welded together, and how Webswing runs a real Java Swing application on your chosen infrastructure, without a rewrite and without locking you in.
The cloud, as the joke goes, is just someone else’s computer. A newer version says the cloud did to servers what ride-hailing did to cars: you summon capacity when you need it and stop paying when you are done, instead of owning the thing and parking it. Both jokes describe a change of arrangement, not a change of identity. The car you hail still carries you; the rented computer still runs your software. So it is strange that “move the Swing application to the cloud” so often gets translated into “rewrite it from scratch.” One is a change of address. The other is a change of identity.
Migrating is not rewriting
They are not the same thing. Migrating to the cloud is a question about where and how your application runs. Rewriting is a question about what the application is, and you can do the first without the second. The pressure that starts these projects is almost always about delivery, access, scaling and operations, and none of that requires throwing the code away and writing it again.
The application already works. Don’t destroy its accumulated correctness.
None of this is a romantic defence of Swing as a joy to write. It is easy to program Swing badly, as Karsten Lentzsch, who spent years teaching teams to do the opposite, once put it. But that is precisely the argument for keeping the application you already have: whatever was written badly in it was found, cursed at, and corrected over twenty years of real use. A rewrite hands all of that hard-won correctness back to a blank page.
Webswing delivers the real Swing app in the browser
Webswing is a specialised web server that runs Java desktop applications directly in the browser with no code changes. The Swing application runs on the server, its interface is rendered in the browser with HTML5 Canvas, and rendering and input events pass between the browser and the server. Nothing is installed on the client. Because Webswing is infrastructure agnostic, that server runs wherever you need it: your own hardware, public or private cloud, containers or VMs, on-premises, air-gapped, or hybrid. It is a real cloud deployment of the actual application, not a reimplementation of it.
What an engineer will ask
Latency. The interface is rendered with HTML5 Canvas and input is sent back to the server. For typical business applications this can deliver a responsive experience in the browser when the deployment is sized correctly and network conditions are sound. And when latency does appear, Webswing gives teams the tools to find where it comes from: HTTP ping latency, server-side rendering latency, client-side rendering latency, and end-to-end frame latency in the Admin Console.
Scaling and cost. Sessions run in pools you size against your own application, so a user is a managed slot in a pool rather than a surprise. For many teams, a well-sized Webswing deployment is easier to justify than funding a multi-year rewrite before users see any value at all.
Security and SSO. There is no Java runtime to install or patch on the client. Access sits behind single sign-on, built-in SAML2 or OpenID Connect, and TLS, and the whole deployment can run on your own infrastructure under your own controls.
Operations and monitoring. Webswing ships as containers, is orchestrated by Kubernetes, and exposes lifecycle and health endpoints. The Admin Console shows session metrics, CPU, RAM and network consumption, latency graphs, logs, and per-session detail.
Resilience and cluster. The cluster server is stateless, so it does not matter which node a browser reaches, even after a refresh. If one cluster server goes down, its connections reconnect through another running cluster server without terminating the application instance, balanced by a session-pool load balancer.
Lock-in. Webswing is available under a perpetual licence. The application is never modified, so you can switch Webswing off and the desktop version still runs, and you can modernise incrementally, in any technology, whenever you decide to.
UX and branding. The surrounding browser experience, branding, login screens, fonts, window themes, and selected presentation details can be modernised without changing the application itself.
What this does not mean
This does not mean every Swing application is automatically an ideal cloud application. Applications heavy on multimedia, video, 3D hardware acceleration, or real-time, game-like interaction are not the right fit, and Webswing needs more server-side resources per session than a native web app. But most business-critical Swing systems are forms, workflows, tables, documents, reports, approvals, and internal tools, exactly the kind of application where central browser delivery is usually a strong fit.
One destination, many roads
The cloud was always a destination, not a rewrite. A rewrite from scratch is a single road: one target stack, one architecture, all of it or none, hard to reverse once you commit, and years before you know whether it worked. Webswing, by contrast, moves the real application to the infrastructure you want in days or weeks, keeps it behaving exactly as it always has, and leaves every later decision open: stay as you are, refresh the surface, or rebuild piece by piece toward whatever comes next. It is step-by-step modernisation, a rewrite in which, if a step does not work out, you can always go one step back instead of all the way to the beginning.
There is an old thought experiment called the Ship of Theseus: if you replace a ship one plank at a time, is it still the same ship? Incremental modernisation is the practical answer, and it is yes, provided the ship keeps sailing while you work. A rewrite from scratch is the opposite: it builds a new ship on dry land while the old one still carries the business, and hopes the new one floats before the old one sinks. One road asks you to bet everything on the end state. The other lets you modernise step by step, without leaving the water.
Sources
• Karsten Lentzsch, First Aid for Swing (JGoodies) – source of the “easy to program Swing badly” line
• NIST SP 800-145, The NIST Definition of Cloud Computing
• Joel Spolsky, Things You Should Never Do, Part I
• Wikipedia, Ship of Theseus (identity through gradual replacement)
• Webswing, Licensing (perpetual licence; no vendor lock-in)
arrow_back_ios
