Updating Getdown

Updating the version of Getdown in an already installed app

Updating Getdown

When you use Getdown to deploy your app, Getdown itself is part of your distribution in the form of the getdown.jar file, but you cannot simply add the getdown.jar file as a code or resource asset to your project and have it automatically updated because this would result in Getdown trying to overwrite its own jar file while it is running.

This does not work at all on Windows, and is dangerous on non-Windows platforms because even though they allow the jar file to be overwritten, any classes not loaded from that jar at the time it is overwritten become a ticking time bomb waiting to crash the app if it attempts to load them from the now overwritten jar file.

Fortunately, there is a fairly simple technique that can be used to update Getdown in a safe and reliable way. The general process is as follows:

1. When you install your app (using the platform specific installer that you create), you install the Getdown jar using a name like getdown.jar.

2. Your app's getdown.txt lists a second copy of Getdown as part of your app's manifest. We usually call this getdown-new.jar but you can name it whatever you like. You will usually list this via a code directive because you will actually run a simple helper function from the Getdown jar in your application code.

3. When your application starts up, you make a call to LaunchUtil.upgradeGetdown and pass it the paths to the getdown-new.jar and the getdown.jar file that was installed by your platform specific installer and it will replace the old getdown.jar with a copy of getdown-new.jar, thereby upgrading the Getdown used to launch your application.

Sample application

The Getdown test app demonstrates this technique. You can look at the pom.xml to see how it includes a getdown-new.jar file in its distribution. The relevant line of the getdown.txt file is here:

# include the latest copy of getdown; app checks at startup whether it should upgrade getdown
code = getdown-new.jar

We also pass the application root directory to the test app via a command line argument so that it can use it when upgrading Getdown. This is accomplished with this directive in the getdown.txt file:

# pass the appdir to our app so that it can upgrade getdown
apparg = %APPDIR%

The main method of the app then uses Getdown to update getdown.jar with the up-to-date copy of Getdown in getdown-new.jar like so:

    public static void main (String[] args) {
        // if we have our appdir, launch a background thread that checks whether to upgrade getdown
        if (args.length > 0) {
            final File appdir = new File(args[0]);
            new Thread() {
                @Override public void run () {
                    LaunchUtil.upgradeGetdown(new File(appdir, "getdown-old.jar"),
                                              new File(appdir, "getdown.jar"),
                                              new File(appdir, "getdown-new.jar"));
                }
            }.start();
        }

        // launch the main JavaFX app
        launch(args);
    }

A few things to note here: upgradeGetdown takes three file arguments: the "old" jar, the "current" jar and the "new" jar. The current jar is renamed to the old jar instead of simply deleting the current jar. This avoids problems if the current jar happens to be in use. Prior to this rename, any old "old" jar will first be deleted. Then the "new" jar is copied (not renamed) to the path identified by the "current" jar.

The end result is that the getdown.jar file is updated with the contents of the getdown-new.jar file and the next time the application is launched, it will be using the upgraded version of Getdown to do so.