OpenRocket, multiplayer, in the browser.

OpenRocket has no collaboration features, so the bridge works from the outside. It snapshots the design with OpenRocket's own .ork writer, compares only the components OpenRocket reports as changed, and sends those properties. Incoming edits go through OpenRocket's file-loader setters in place; adding, removing or moving parts reloads the rocket the way OpenRocket's undo does. Undo reverts only your own edits, simulation results remember exactly which version of the design they were computed for, and the edit history can undo one person's change while keeping later changes by others.

• CheerpJ's Java 17 lacks the reflection natives behind type annotations, which OpenRocket's dependency-injection library asks for; the page supplies them (“no type annotations”).
• OpenRocket finds its plugins by scanning its own jar, which cannot run under CheerpJ; the browser build ships a plugin list computed at build time.
• Two Java threads setting up XML at the same moment failed at random, and so did loading runtime files while Java was running. Warming up XML on one thread and preloading the runtime files took fresh starts from 4 successes in 9 to 6 in 6.
• The 3D view needs OpenGL, so it uses OpenRocket's own switch for computers without 3D.

Base44 accepts at most 50 MB per site and the official jar is 83 MB. Most of it is the JavaScript engine behind the Scripting simulation extension plus native libraries for desktop systems, none of which can run in a browser. Removing only those gives a 42 MB jar with OpenRocket's own code untouched. CheerpJ reads it with HTTP range requests, so visitors download only the parts they use.

In the browser every Java thread shares one thread, and CheerpJ never switches away from a busy one. Chrome's profiler showed that OpenRocket's background flight-estimate simulation, re-run after every change, held the window for 2–3 seconds per edit. With that preference off by default (it is OpenRocket's own setting), an edit takes about 0.4 seconds; long-running simulations also pause briefly so clicks get through.

Each design room stores the design in 64 hashed buckets, each split into values under 96 KB, so an edit rewrites only what it touched. Messages over 400 KB (simulation results, decal images) travel in fragments, and the room handles events strictly one at a time so two edits never interleave. Locally, the same room code runs behind a plain WebSocket server for tests.

With the random wind seed fixed, the browser and desktop Java agree on the example rocket's apogee, velocity and flight time to 8–13 significant digits, the same level at which two desktop computers differ (Java allows math functions such as sine to differ in the last digit). Mass and centre of gravity match bit for bit.