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
Related
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.
I have developed a JavaFX app and I am going to distribute it as a Native Package to avoid headaches with users having a Java version lower than 7 (and thus, without JavaFX) or having no Java at all.
However, I also want to be able to deliver updates of my application. One solution is for the app to call home (its already communicating with the backend via XMLRPC), fetch a JAR and self-update. I can see potential problems with the actual update process though (would need to build a separate updater program, but how do you update the updater?).
I know about and would love to use Java Web Start. However, I have no idea if this will work with the Native Package thing. If the user already has Java installed, it will disregard my bundled JRE. If he has no Java... well, he can't use Java Web Start, right?
How can I solve this problem in an elegant way that will not have a detrimental effect on user experience? (and preferably won't be very long to implement)
note: I am using e(fx)clipse as build tool.
If he has no Java... well, he can't use Java Web Start, right?
True, but as mentioned in the JWS tag Wiki:
Java Rich Internet Applications Deployment Advice. Describes the deployJava.js
script designed to ensure a suitable minimum version of Java is installed before
providing a link to a
JWS app.
or launching an
applet.
Note that JWS also offers fine grained versioning as detailed in Java Web Start - Runtime Versioning.
Saying that, JWS can allow you to support earlier systems by adding the JavaFX 2 API selectively to those earlier systems. That is achieved using a version based resources section in the launch file.
So, JWS combined with deployJava.js would actually be 'the alternative' to the Native Package that page discusses.
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 developing an inventory system i-e a java desktop application. I am using Ms Access as database engine and there are certain modules e.g one makes reports using ireport and other such dependencies. I need to ask how can I make installer for my application which will install few fonts, copy database files, install jre to make it run etc. Please guide me in it.
Thanks in anticipation.
This is something I've briefly used in the past, and it may serve your needs. It's an open source installer builder system, tailored towards Java apps.
http://izpack.org/
I've used jsmooth which creates a single EXE-file that unpacks and run transparently. Not a full installer but worked well for us.
Note: I have not seen any Java installers which asks the "There is an update available. Update now?" question.
If this is important to you, then consider Java WebStart which checks for updates at each launch (but do not ask).
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.