Getdown deployed Java apps before Java Web Start was deprecated, and it is now unmaintained

The first thing the README says is who to use instead

The README opens with a section titled Use the fork, Luke, and it is the most useful paragraph in the document.

This original Getdown project is not actively maintained, but there is a fork by `bekoenig` that is actively maintained, at github.com/bekoenig/getdown, and the README recommends using that fork if you can.

That is worth reading before anything else, because Getdown is a case where the upstream repository is a historical artifact and the working version lives elsewhere. The last push to this repository was on 2026-10-12, so there has been recent activity, but no releases are listed, and the recommendation stands.

The history behind the project explains why it exists at all. It was designed as a replacement for Java Web Start, due to limitations in Java Web Start's architecture which are outlined in the rationale section of the wiki.

But the README is careful about the scope of that claim. Getdown was designed in 2004 as an alternative to Java Web Start, because of design choices made by JWS that were problematic to the use cases its authors had. It is not a drop-in replacement for JWS, aimed to help the developers left in the lurch by the deprecation of JWS in Java 9. It may still be a viable alternative for developers looking to replace JWS, but don't expect to find feature parity with JWS.

So the project is a twenty-year-old answer to a problem Oracle created and then removed, and the honest framing is that it is a revival option rather than a modern deployment system.

What it does, and the packaging cost that comes with it

Getdown is a system for deploying Java applications to end-user computers, as well as keeping those applications up to date.

The architecture is a launcher plus a core library plus an Ant task, and understanding the split is necessary because it determines what you integrate with.

The launcher is what actually runs on the user's machine. It is minified via Proguard, and it is what updates and launches your app. It also contains the tools needed to build a Getdown app distribution, so it is the artifact your build needs at minimum.

The core contains the core logic for downloading, verifying, patching and launching an app, as well as the core logic for creating an app distribution. It has no user interface code, and the README says you would only use this artifact if you were planning to integrate Getdown directly into your app.

The Ant task is for building an app distribution, with the build integration instructions covering the details.

The packaging cost is the part that gets underestimated. Because one can not rely on users having a JRE installed, you must create a custom installer for each platform you plan to support, Windows, macOS and Linux, and each installer installs a JRE, the Getdown launcher jar file, a stub configuration file that identifies the URL at which your real app manifest is hosted, and whatever the appropriate desktop integration is that provides an icon the user can click on.

So you are building three installers, each bundling a JVM. That is the reason the project is not a general purpose updater, and it is the reason most teams reach for something else.

The three Maven artifacts and where to get them

Getdown will likely need to be integrated into your build, and the README says you can also download the individual jar files from Maven Central if needed.

The three artifacts are under the com.threerings.getdown group.

getdown-launcher contains the minified Proguard code that you actually run to update and launch your app, and it also contains the tools needed to build a Getdown app distribution.

getdown-core contains the core logic for downloading, verifying, patching and launching an app as well as the core logic for creating an app distribution. It does not contain any user interface code, and you would only use it if you were integrating Getdown directly into your app.

getdown-ant contains an Ant task for building a Getdown app distribution, and the build integration instructions cover the details.

The README also lists the alternatives: check out the code and build it yourself, browse the source code online, and view the javadoc documentation online.

The distinction between the launcher and the core is the one to hold on to. Most integrators want only the launcher, because they are building a distribution that a user's machine runs. The core exists for the unusual case of embedding Getdown's own update machinery inside an application that is itself a launcher, which is what OOO did with its games.

JVM requirements across the version history

The JVM version requirements section is a plain list, and it is a useful proxy for the project's age.

Getdown version 1.8.x requires Java 7 VM or newer. Version 1.7.x also requires Java 7 VM or newer. Version 1.6.x requires Java 6 VM or newer. Version 1.5 and earlier requires Java 5 VM or newer.

So the current line targets Java 7 as its floor, which is a version long out of support and which no current JVM ships. If you are bundling a JRE with your installer, as the README requires, you are bundling something that has had no security updates for years.

This is the sharpest practical constraint on adopting Getdown today. The project was written for an era when a Java 7 runtime was a normal thing to ship, and the packaging model it assumes is exactly the one that makes that era's problems hard to solve.

There is also a migration document for people moving from Getdown 1.7 to 1.8, on the wiki, which tells you that the 1.8 line was itself a breaking change.

The build is Maven, and the README gives the standard commands.

% mvn compile  # builds the classes
% mvn test     # builds and runs the unit tests
% mvn package  # builds and creates jar file
% mvn install  # builds, jars and installs in your local Maven repository

The repository root holds the standard Maven layout, with core/, launcher/, ant/ and lib/ directories alongside pom.xml, plus a CHANGELOG.md, an AUTHORS file and a LICENSE.

Where it came from, and why it is still interesting

Getdown was originally written by developers at OOO for the deployment of their Java-based massively multiplayer games, and the README names two of them: Puzzle Pirates and Spiral Knights.

That origin explains the design better than any amount of documentation. OOO ran games that had to be installed on thousands of consumer machines, on connections that were slow and unreliable, and the update problem they faced was not the same one a web deployment has. Their games needed to keep working when the network did not, and they needed to push patches to players who had installed the game months earlier.

That is why the project emphasises verifying and patching rather than just downloading, and why it was an alternative to Java Web Start rather than a simple installer.

The design page in the wiki is where the operational details live, and the README points there for the main design and operation of Getdown, alongside the javadoc and the source for implementation details. Questions can be posted to the OOO Libs Google group, and a tutorial with more detailed specification is on the Documentation page.

For a team today reviving an old JVM desktop application, this history is the argument for reading it. Getdown solved the problem of pushing an update to a Java application that a user installed years ago, over a connection that might be gone, with a verification step in between. That problem still exists, and the design decisions are documented.

Where Getdown is the wrong choice

Four cases argue against it.

The first is new work. The upstream says it is not actively maintained and points to a fork, and the Java 7 floor plus the three custom installers with a bundled JVM make it a heavy choice for anything starting today. A modern alternative gives you a signed installer, an auto-updater and code signing in one package.

The second is a non-JVM application. The README is direct: while it would be technically feasible to use Getdown to deploy non-JVM-based applications, it is not currently supported, and it is unlikely that the overhead of bundling a JVM just to run Getdown would be worth it if the JVM were not also being used to run the target application. That is a sensible engineering judgement, and it closes the door on using Getdown as a generic application updater.

The third is a team that expected Java Web Start parity. The README says not to expect feature parity with JWS, and given that JWS had native integration, signing and security dialogs from the JVM, that gap is wide.

The alternative in the same direction is a conventional update mechanism, such as an electron-updater style self-updater for a packaged application, or an OS-level package manager if your users can install software. The difference in approach is that Getdown exists to update a Java application without the user having a JRE, and its launcher handles a partially broken or absent previous installation, which is what JWS did and what a normal installer cannot. For an internal enterprise tool on managed machines, a managed deployment tool is a better answer. For a consumer game with a long tail of installations, Getdown's model is closer to what you need, which is why a fork of it is still being maintained.

Editorial conclusion

Getdown fits a team reviving a JVM desktop application that was distributed through Java Web Start and wants the launcher and update logic back, since the three Maven artifacts are still on Maven Central and the design documentation is still online. It does not fit new work, because the original project says it is not actively maintained and points to a fork by bekoenig. Read the rationale in the wiki before you choose it over a modern updater, and note the packaging cost the README describes: a custom installer per platform, each bundling a JRE, the launcher jar, a stub manifest pointing at your real app URL and the desktop integration.

Frequently asked questions

Official sources

1. Issues
2. README
3. threerings/getdown on GitHub