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.
Related
I'm about to write a new cross platform application, and I choosed JavaFX, mainly because of its rich UI libraries (both standard and third party) and it native data binding feature. My application will be deployed via native packaging, both because the lack of PPAPI Java plugin (Chrome will discontinue NPAPI in Chrome 42, which is in beta now) that would prevent an user with Chrome to use WebStart, and because a more "classic" user experience, so WebStart and automatic updates are off the table.
The scenario would be the following:
Application starts and checks for updates
If updates are found, download them and put them in a temporary folder
At application shutdown, write the newly downloaded JAR files over the old ones
Automatically restart the updated application
However, a few question arises in my mind (initially these two, but I could be updating this question as soon as I have more):
Is it safe to do so? Am I risking that somehow the JVM gets crazy if I overwrite some of the JARs already used in the application lifecycle?
I'm struggling to find a way to automatically restart my JavaFX application. Is it even possible?
Thanks everyone for your help.
Take a look at GetDown or UpdateFX. It implements a bootstrap downloader that checks for updates, downloads them and starts your Application as soon it is updated
I've recently created update4j which works with Java 9's module system and meets your requirements.
Perhaps you can try install4j though it's paid. The main feature here that I love the most is the auto update and the way you can configure the installer in an easy way (create Linux - deb,rpm installer, Mac and window installer) and can even package the required jdk version to run your app (this means your users do not need to have that java version installed first before using your app)
Though, it might seem a bit overkill foe your needs
I have a jar file which contains two Java classes. Using the javamail API I have developed these classes to read and edit my mail, then send to another mail id.
I am able to execute this through my standalone system via Eclipse. Now I want to host this jar file somewhere remotely so that it would fetch the data in real time and execute the job regularly. I have contacted couple of hosting sites and they are saying that they require a war file instead.
Does anyone have any suggestions to this problem?
To give you another point of view and to be constructive, I would go with embedding your jar into a war application and you get some things for free, the most important I think is that you gain a managed application lifecycle so with a standard web application context listener you can start and stop your program in a managed way. Besides you have more hosting options and it is less work.
Good luck with that.
As I don't know of any services specifically for plain execution of executables, your best bet is probably getting a cheap VPS. With some searching you can probably find one that would work for around $5 USD/month. For a single simple app you'd only need around 128MB of memory.
Pick one up, install Java (whatever Linux distro you get probably has OpenJDK in the repositories), copy your files over, and set up a cron job to run the executable at a set interval.
For easier administration, install something like webmin and use that to configure the cron job. The command would likely just be java -jar /path/to/my/App.jar, and you can use the web interface to configure the intervals for the command to be executed.
For an app like this, I would avoid anything related to a war file. You aren't making an application with a web interface (like a PHP app or some such) so it really wouldn't be appropriate. You would have to write some extra code to make it compatible with a container like Tomcat, and on top of that the memory requirements for running the application server would be a lot higher.
Problem: I have a standalone Java app (henceforth known as "the agent") that runs as a service on internal company servers. It acts as a remote agent for some central servers. As the agent gets deployed in more places, managing them is getting more complicated. Specifically: pushing updates is painful because it's a fairly manual process, and getting access to the logs and other info about the environments where the agents are running is problematic, making debugging difficult. The servers under discussion are headless and unattended, meaning that this has to be a fully automated process with no manual intervention, hence Java Web Start isn't a viable solution.
Proposed solution: Make the agent phone home (to the central servers) periodically to provide agent status and check for updates.
I'm open to other suggested solutions to the problem, but I've already got a working prototype for the "status and self-updates" idea, which is what this question is focused on.
What I came up with is actually a separate project that acts as a wrapper for the agent. The wrapper periodically calls the central server via HTTP to check for an updated version of the agent. Upon finding an update, it downloads the new version, shuts down the running agent, and starts the new one. If that seems like an odd or roundabout solution, here are a few other considerations/constraints worth noting:
When the wrapper gets a new version of the agent, there may be new JAR dependencies, meaning class path changes, meaning I probably want to spawn a separate Java process instead of fiddling with ClassLoaders and running the risk of a permanent generation memory leak, which would require manual intervention--exactly what I'm trying to get away from. This is why I ended up with a separate, "wrapper" process to manage the agent updates in my prototype.
Some servers where the agents are deployed are resource-limited, so any solution needs to be low on CPU and memory usage. That makes me want a solution that doesn't involve spinning up a new JVM and is a stroke against having a separate wrapper process.
The agent is already deployed to both Windows and RHEL servers, so the solution must be cross-platform, though I wouldn't have a problem duplicating a reasonable amount of the process in batch and bash scripts to get things rolling.
Question: As stated, I want to know how to make a self-updating Java app. More specifically, are there any frameworks/libraries out there that would help me with this? Can someone with experience in this area give me some pointers?
If your application is OSGi based, you could let OSGi handle bundle updates for you. It is similar to the wrapper approach you suggest, in that the OSGi container itself is "the wrapper" and some of it won't be updated. Here's a discussion on this
Different solution: use (and pay for) install4j. Check out the auto-update features here
No need for wrapper (save memory) or java web start (adds more restrictions on your application), simply let a thread in you application check periodically for updates (e.g. from cloud) and download updates if available, then code these two calls in you application:
launch a shell script (.sh or .cmd) to update your artifacts and launch your application after few seconds pause in the script(to avoid having two instances of your application at the same time).
Terminate your application (first instance)
The script can overwrite needed artifacts and re-launch your application.
enjoy !
Have a look at Java Web Start.
It is technology that's been part of Java since... 1.5? maybe 1.4? and allows deployment and install of standalone Java-based apps through a web browswer. It also enables you to always run the latest app.
http://www.oracle.com/technetwork/java/javase/overview-137531.html
http://en.wikipedia.org/wiki/JNLP#Java_Network_Launching_Protocol_.28JNLP.29
also see this question: What's the best way to add a self-update feature to a Java Swing application?
It appears as though Webstart is the only built in way to do this at the moment.
I am wondering if it is possible to have a Java desktop application, on startup, look to some URL, to see if it needs an update, and if so download necessary JAR files, and add them to classpath for the running program.
If the old jars are there, they shouldn't have been loaded into the classloader yet, at this point should they? Is it possible to swap them out before they are loaded w/out restarting the application?
JNLP (Java Web Start) will do all of that for you.
It should be possible. The URLClassLoader is a place to start.
It's possible but prone to error.
A somewhat cleaner approach is to have a "launcher" application which does not rely on any of the updatable JARs do the above and then launch the actual app.
You may want to check out this question for more details on this topic.
Java Web Start is probably your best bet. The required jar files should be identified in the descriptor allowing your to manage the version control.
If you have a dynamic application that needs to discover and download classes dynamically at runtime, then you could look at Dynamic code downloading using RMI.
Java Web Start is a good choice but has some quirks. Notably:
Code which is updated must be downloaded before the program starts. A more modern approach would download updates and apply them at next start.
Default is inside a sandbox. If you need to go outside of that you must sign your code, which is rather cumbersome until you automate the deployment process (or use Netbeans which helps quite a bit).
Problems are not easy to debug - only tool is enabling full trace in the Java Console.
Caching of jars in the client is error prone. When you update, be sure that the URL is unique for each deployment component so the cache will not be used.
But WHEN it works it works pretty well. It is to my knowledge the easiest way to have a centralized version easily updateable of a given Java application.
--
EDIT: It appears that the "start program and transparently download updates if available" functionality is present in the latest Java 6. I have not tried it yet, but will soon.
I'm trying to figure out a way to add a self-update feature to a Java/Swing application I'm working on.
Basically I've got a bunch of jar files with extra functionality to be re-deployed to the installed users when they change. Nothing complicated, just check if a new version has been released, download them over HTTP, and then optionally offer to restart the app to the user.
I had a look at webstart, and it could work. But this particular app does some funky stuff with classloading and GC memory settings that don't look like they are supported via webstart, or will at least complicate matters. (It's a tweaked build of JMeter)
I also went down the road of adding in this plugin handler http://swing-fx.blogspot.com/2008/06/add-auto-update-and-plugins-to-your.html, but it is very alpha, and tries to do too much with the usual bugs you get with alpha stuff.
I did the exact same thing. But that was long back so there are probably better tools today.
What I found out I needed was a loader. The loader main program did not have the app jars in classpath. It first downloaded an update if required and then created a custom classloader with the app jars in class path and invoked the main method of the application main class. It is not very complicated. IIRC I needed to do this because the jars could not be overwritten in windows if they were already in classpath.
Hope this helps.
we had a swing app 6 years ago that had self-update. like you suggested,
1)it downloaded the latest jars over http,
2) copied them to a folder.
3) since the swing app is launched using a .BAT file, after user said YES, we would shut down the swing app and look for any files in the update folder. if yes, launch another .BAT file to copy the NEW JARs to the required directory.
4) then re launch the swing app.
Updates, plugins, separation of concern etc. are exactly what OSGi is about - you might want to take a look at this. It won't come free (read: with a steep initial learning curve, especially when you are currently using classloading tricks) at least there are good open source implementations (felix - see felix.apache.org, equinox - see www.eclipse.org and others)
For these implementations autoupdaters are available - if you write your modules correctly it's possible to update at runtime without restarting.
I believe you should look again at Java WebStart, or at least detail the "funky classloading" which you think is going to cause problems (as it might also cause problems with any solution proposed here).
IIRC, you can set command line parameters using Java WebStart ( http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources ).
I would definitely first try out Webstart. We've had lots of success launching even the early Eclipse RCP apps using Webstart, and you can probably not get more funky classloading issues than with the OSGI framework (Eclipse Equinox).
Could you perhaps give some more detail in your question about you classloading approach?
Regarding the GC and other VM settings: these are easy to specify in your JNLP (Java Network Launching Protocol) files used by Webstart for launching apps.
The Java Web Start is good choice. The GC stuff is not important. Classloading could be problem. But when you got trusted by user you can grant AllPermisions and you will be able to do custom classloading. Maybe it will be good to reconsider funky stuff with classloading. It is really necessary? Or look at NetBeans. There should be found inspiration for auto-update.