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.
Recently I found an interesting Java applet which works pretty fine for electronic signature, but due to the recent NPAPI stuff with Chrome browser, I've considered it would be a good thing to migrate this applet to a Java application. HTML5/javascript/etc is not a possibility.
The special requisite is that the application should be launched from a browser, despite not being an applet.
The best approach I have found is as follows:
Create an installer which would create a java executable file in the local user's PC.
Create a javascript function to detect whether the application is installed in the computer (just as iTunes does/used to do).
In order to launch the application, create a custom URI Schema handler which would launch the application when found, sending the required parameters to the application (just like the applet does).
Everything sounds pretty smooth, but it's got certain drawbacks:
It's meant to work on different PC's. That means the URI Schema handler and the application MUST be installed/set up in every single computer I want to use the application in.
Migrating the applet code to a java application. It is an old application which i did not write, and it's got a single class with over four thousand lines.
With that in mind, I could not think of a better option. Is this viable? Any recommendation?
Thanks in advance.
I have a desktop Java application that is run from the command line, which takes in some arguments and performs some actions based on these arguments.
Currently, the application is instantiated periodically, performs its function and then exits.
The issue is that the users are unhappy with the amount of time it takes for the application to initialize. In order to work around this, I thought of simply toggling the visibility of the application when it is finished and setting up some kind of IDLE state.
I was trying to figure out a way to pass in new arguments next time the application needs to do work. I found out about SingleInstanceService and was wondering if it is possible to make this work with my application? It's unclear to me what I need to do so that the Single Instance Service runs on the client PC.
Alternatively, is there another solution for my communication problem? I would rather not depend on File I/O to trigger the application's logic.
Thanks.
AFAIK The JNLP API is available only if you launch your application using java web start (JWS) technology: read more here: http://java.com/en/download/faq/java_webstart.xml
If that is an option for you, oracle has some example of how to use the SingleInstanceService here
Implement and Register SingleInstanceListener. It will be invoked with the main-args when new instances of your application is launched.
In the company where I work we have, among others, an application made in Java running on two places (let's say Merida and Coatza) and both have different databases. The users from Merida only occasionally used the program to get some info or capture things. Now the company owner decided to control almost everything from Merida but we cant get the databases merged due to operation logistic.
The thing is that when the application uses the persistence-unit to connect coatza it's incredibly slow since the app its not prepared to use remote databases (at least not with a high performance).
I thought of something like teamviewer to run the app remotely but not the database, however I don't want to run the complete desktop, only the application. Or develop a part of the program on JCurses so it can be run from coatza but there is not enough documentation and we use a lot of tablemodels.
Is there something I could do?
The application is a DesktopApp. We use Jboss 5 as server. Hibernate and JPA.
I had a similar situation where we needed to use the same application at different locations because the license was too expensive. I used a feature called RemoteApp on Windows Server 2008. The best part is that you can have a desktop shortcut for any app on a remote computer and all you need to do is open it and login and only that particular app starts running instead of the whole desktop. There is also a web interface for remoteapp so that you can simply login and select whichever app you want to run. For more details take a look at http://www.techotopia.com/index.php/Configuring_RemoteApps_on_Windows_Server_2008
I am confused about the approach for application that am writing. I have developed the application jar and will be distributing via java webstart.
Now i need to putup a website supporting my app.
doubts i have
1)Can i pass this username and password to the jar that i will be launching?
2)Can the webcomponent calculate the time for which the app was launched.
Basically i need to understand how will the webcomponents and my java app interact with each other in terms of any data required to pass to the app and any info retreaving from the app and putting on the web.
Thanks
Krisp
I want to pass arguments like username to the JNLP and then want to pass it to the main class.
Is there any direct way to do so rather than use database?
since JNLP is just an xml file. I could not find a direct way to do so.
Can i anybody refer me some working code example.
Database is probably your best bet for sharing data between both apps. Other options are web services, sockets, RMI, etc.. You will probably need to look into all, on the surface initially, to know what suits you best.
As for the Calculation of the time in my java app i can use currentTimeMillis() to calculate the time for which my app is running.
But senarios like app getting crashed or forced termination of the app it will not get saved.
Any Hints for communication in terms of data between the web and Application jar?
Thanks
Krisp