11

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.

Improve this question
5
  • 3
    You are revinventing the wheel and you already know so, since you mention Java WebStart. The deployment on the server is minimal, you only need to post a few files, there is no need for an active component on the server. Commented Sep 7, 2009 at 12:05
  • I suggest using a certificate rather than checking a hash from https. With the hash technique, a compromised https server means compromising all autoupdating clients. / Also check that you are installing a more current version to avoid downgrade attacks. / WebStart does give a limited interface to using files, although control/customisation of the file browser is limited. Commented Sep 7, 2009 at 12:07
  • I think that It's not so minimal. I need to deploy it in a server not controlled by me at all. I can't change mimetypes for example. Besides, as I've said, It would need to access local files so I would need to sign it. Commented Sep 7, 2009 at 12:09
  • Well, so I can use JWS sandbox to open/save files without signing. In that case, I'll try JWS again. Commented Sep 7, 2009 at 12:28
  • An update from the future: JavaWS is long gone. Commented Aug 18, 2023 at 1:36

1 Answer 1

Reset to default
5

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

In case anyone looks for a example on how to do it, I built pretty much that over the last few days: github.com/UrsKR/updates-r-simple

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.