I would like to implement a java application (server application) that can download a new version (.jar file) from a given url, and then update itself at runtime.
What is the best way to do this and is it possible?
I guess that the application can download a new .jar file and start it. But how should I do the handover, e.g. know when the new application is started and then exit. Or is there a better way to do this?
The basic structure of a solution is as follows:
There is a main loop responsible for repeatedly loading the latest version of the app (if required) and launching it.
The application does its thing, but periodically checks the download URL. If it detects a new version it exits back to the launcher.
There are a number of ways you could implement this. For example:
The launcher could be a wrapper script or binary application that starts a new JVM to run the application from a JAR file that gets replaced.
The launcher could be a Java application that creates a classloader for the new JAR, loads an entrypoint class and calls some method on it. If you do it this way, you have to watch for classloader storage leaks, but that's not difficult. (You just need to make sure that no objects with classes loaded from the JAR are reachable after you relaunch.)
The advantages of the external wrapper approach are:
you only need one JAR,
you can replace the entire Java app,
any secondary threads created by the app, etc will go away without special shutdown logic, and
you can also deal with recovery from application crashes, etc.
The second approach requires two JARs, but has the following advantages:
the solution is pure Java and portable,
the changeover will be quicker, and
you can more easily retain state across the restart (modulo leakage issues).
The "best" way depends on your specific requirements.
It should also be noted that:
There are security risks with auto-updating. In general, if the server that provides the updates is compromised, or if the mechanisms for providing the updates are susceptible to attack, then auto-updating can lead to a compromise of the client(s).
Pushing a update to a client that cause damage to the client could have legal risks, and risks to your business' reputation.
If you can find a way to avoid reinventing the wheel, that would be good. See the other answers for suggestions.
I am currently developing a JAVA Linux Daemon and also had the need to implement an auto-update mechanism. I wanted to limit my application to one jar file, and came up with a simple solution:
Pack the updater application in the update itself.
Application: When the application detects a newer version it does the following:
Download update (Zipfile)
Extract Application and ApplicationUpdater (all in the zipfile)
Run updater
ApplicationUpdater: When the updater runs it does the following:
Stop the Application (in my case a daemon via init.d)
Copy the downloaded jar file to overwrite current Application
Start the Application
Cleanup.
Hope it helps someone.
I've recently created update4j which is fully compatible with Java 9's module system.
It will seamlessly start the new version without a restart.
This is a known problem and I recommend against reinventing a wheel - don't write your own hack, just use what other people have already done.
Two situations you need to consider:
App needs to be self-updatable and keep running even during update (server app, embedded apps). Go with OSGi: Bundles or Equinox p2.
App is a desktop app and has an installer. There are many installers with update option. Check installers list.
I've written a Java application that can load plugins at runtime and start using them immediately, inspired by a similar mechanism in jEdit. jEdit is open source so you have the option of looking to see how it works.
The solution uses a custom ClassLoader to load files from the jar. Once they're loaded you can invoke some method from the new jar that will act as its main method. Then the tricky part is making sure you get rid of all references to the old code so that it can be garbage collected. I'm not quite an expert on that part, I've made it work but it wasn't easy.
First way: use tomcat and it's deploy facilities.
Second way: to split application on two parts (functional and update) and let update part replace function part.
Third way: In your server appliction just download new version, then old version releases bound port, then old version runs new version (starts process), then old version sends a request on application port to the new version to delete old version, old version terminates and new version deletes old version. Like this:
This isn't necessarily the best way, but it might work for you.
You can write a bootstrap application (ala the World of Warcraft launcher, if you've played WoW). That bootstrap is responsible for checking for updates.
If an update is available, it will offer it to the user, handle the download, installation, etc.
If the application is up to date, it will allow the user to launch the application
Optionally, you can allow the user to launch the application, even if it isn't up to date
This way you don't have to worry about forcing an exit of your application.
If your application is web based, and if it is important that they have an up to date client, then you can also do version checks while the application runs. You can do them at intervals, while performing normal communication with the server (some or all calls), or both.
For a product I recently worked on, we did version checks upon launch (without a boot strapper app, but before the main window appeared), and during calls to the server. When the client was out of date, we relied on the user to quit manually, but forbid any action against the server.
Please note that I don't know if Java can invoke UI code before you bring up your main window. We were using C#/WPF.
If you build your application using Equinox plugins, you can use the P2 Provisioning System to get a ready-made solution to this problem. This will require the server to restart itself after an update.
I see a security problem when downloading a new jar (etc.), e.g., a man in the middle attack. You always have to sign your downloadable update.
On JAX2015, Adam Bien told about using JGit for updating the binaries.
Sadly I could not find any tutorials.
Source in German.
Adam Bien created the updater see here
I forked it here with some javaFX frontend. I am also working on an automatic signing.
It is as simple as an application that can update itself.
More specific, maybe a launcher that loads a jar file from the web and replaces it with the current jar.
The approach that I want is:
A launcher which is coded in Java.
That launcher overall uses classloader e.t.c.
I want to keep the data from the previous jar. Maybe the data from the previous jar are written on a .txt file and pass them to the new one? (If possible)
I have no clue about classloader or any direction to follow.
So my question is "How can i use classloader to create an auto-update Java application?".
P.S. I want java web start to be the last choice. Some lines of code would help me very much.
Edit: I understand completely what are you saying in theory. What i am looking for is specific links or code which i can take as reference.
The question isn't a duplicate because i can't find links or code but theory.
You can use the URLClassLoader to load a jar file from an URL. Mind, URLs may also be local files, and I'd recommend that you download the jar file locally before loading it in, instead of loading it directly from the web. The reason for this is that you want the application to remain usable, even if the user cannot reach your server.
However, I'd also recommend against taking this approach. What if you want to update the launcher? It's better to download a seperate updater application from the main application, launch the seperate updater application, have that kill the main application and update it.
I'm trying to make a Java game updater launcher for my game. Similar to how minecraft works. However, minecraft has only a few .jar's to download wheras I would need to redownload all of my game assets. Is there any easy way for Java to check a file for which operations need to be taken? One idea I had was using .7z files since those can be compressed really small. That wouldn't work though because I can't seem to get Java to hook onto 7zip operations. Another idea I had was if it determined if an update was needed it would read a file with a set of commands like this:
remove assets/models/malecharacter.obj
add assets/models/alien.obj
...etc
But I'm not sure this is very efficient and I am also not able to find a lot of help with managing files. Any help and ideas would be appreciated.
I made a Game Launcher in Java recently, I still have a few problems to solve like how to update the launcher itself.
Anyhow, for the game updates/versions I just have a "versions" folder with a folder for each downloaded version, it might not be the prettiest of solutions but it works for multiple versions and it's easy to make.
My launcher checks a URL from my dedicated server which has all available versions, which I call it versionlist, then since the versions folder on the server obeys a path order I can call any versions which are in the versionlist. I download the selected version and extract it to a separate version folder on the user's pc.
I'm looking for a non-webstart/jnlp solution.
I'd like to add to my app an update feature that checks in an ftp or http server and downloads the last version (if there is a newer one) replacing the libs that has been changed.
How can i do that? I want to implement something like JDownloaders updates.
Thanks
It looks like you just described exactly how to do it. Add an update feature that checks an FTP or HTTP server and downloads the latest version.
Remember that you cannot download and overwrite a file which is in use. So you have two options for a design from where I sit:
When you start up the application, copy all of the jar and library files to a /temp folder of some sort before running them. Then, when you download the update, overwrite the files in the original place. The next time the application starts up, it will use the new files.
When you start up the application, first startup an updater. Have it connect to the server and compare all of the file versions. It will be able to overwrite any of the application files because it doesn't use them. It only uses the updater jar. Once this is done and everything has been updated, then start a new process from the updater with the actual application. You will also need to put some code in to be able to update the updater jar. Either make the main application be able to update the updater, or use the first technique and run the updater from a copy of the updater jar.
Remember when you download the files that you should be downloading them to a temporary location and then moving them to the right place when they're done. This will make sure that you never leave your application in a "half-downloaded" state.
Beyond that, getting this to work is going to be about a lot of testing. Good luck!
Have a look at http://code.google.com/p/getdown/
According to this question on stackoverflow it seem to be a viable alternative for web start (at least worth having a look at).
On his blog Scott Kovatch writes:
Without getting into too much detail, typing ‘java MyAWTCode’ from a Terminal window violates a whole lot of assumptions about what an application is on Mac OS X, and needs a lot of cooperation between the AWT and the Process Manager to sort it out.
http://skovatch.wordpress.com/2011/01/03/secret-smoke-screens/
Out of curiosity - what assumptions are violated? Surely this is just a candidate for an API call with callbacks?
Sure, I can elaborate on that a bit.
The Process Manager starts with the assumption that all applications that present a UI on Mac OS X are bundled, are packaged in a folder named Application.app, binary in Contents/MacOS/Application, and most importantly, have an Info.plist to get things like the name of the application that will be shown in the application menu. When you run a Java application from the command line (Swing or SWT) there is no Info.plist, so we had to create a CFDictionary to be passed off to a private SPI that would register the application, give it a proper name in the Dock -- as opposed to just 'java' -- and could be force-quit.
Even then, it's not perfect, because the Dock also assumes it can store an alias to the bundled application when you right-click and choose Keep In Dock, but since there isn't one that fails silently. There's no way to store a shortcut or command line to start the application like Windows can.
The SWT just calls TransformProcessType, which is a start but is nowhere near sufficient to turn a Java application into a full UI application. For doing pure SWT testing and development it's enough to get you going. When you create an Eclipse RCP-based application for deployment you end up with a bundled application with the Eclipse launcher, and plugins and features, and you're ready to go.
Of course, if you go the extra mile and package your Java application into a bundle, this is all moot, but the vast majority of developers coming from other platforms don't bother and just want to run an executable JAR file or even a folder of class files with a shell script.
I am not sure what he had in mind, but I guess a big difference is the file structure: a normal MacOS X application is a bundle with the structure NameOfTheApp.app/Contents/MacOS/NameOfTheApp , and specific files in the Contents directory. When we use the terminal with a "java" command, the JVM has to create a "virtual" application specific to the Java code, and handle all the MacOS events for it. Also, when you open an application twice in the Finder, it simply activates the application the second time, while you need to launch separate applications every time you use "java MyAWTCode".