I've developed a desktop Swing app and I'm thinking about the best way to provide the autoupdate feature.

I know that JavaWebStart provides this but I think that It doesn't suit my needs because I need to read local files so I would need to sign the jar. Besides, JWS requires extra work to deploy in the server while now I only need to upload the .jar.

I've been thinking about this approach:

A first JAR (which never needs updating) loads the splashscreen, checks the current version in a config.xml and compares it to the server config.xml.

If server version is newer, ask the user whether he wants to update. In that case, download the new "main.jar", the new "config.xml" and the new splash/icon, check MD5SUM, and replace the old files with the new ones.

Launch "main.jar".

I don't know If I'm trying to reinvent the wheel or If there's a better pattern than the one I've put above.

We did a similar thing. We just got it via https and downloaded the jar. To know if you need a new one we just check the size on the stream. Theoretically that may not work, but in practice it did. We got even fancier by getting the directory listing where the jars were located, parsing it and downloading each jar, so the name of the jar wasn't hard coded either. There are a couple of ugly points, though.

First was launching a new jvm process to start the new jar is a not so simple.

Second, you have to be sure you don't corrupt your jar if your update fails in the middle.

Finally, there is no way to update the bootstraping jar with this process.