I have an application that has the ability to update myself. It downloads the jar file from the network, and then tries to replace the used jar to run this application by downloading it. But I can’t do this because the file is locked by windows, because the application is still running.
Does anyone know about this?
One popular solution for this is to run your update as a standalone program. Have you ever noticed that Firefox should restart when it is updated? This is because a separate process (updater.exe) updates the files and then starts Firefox again.
You can try this approach. The only obstacle I see in the way is trying to automate the MAIN program to close it. The only portable way to do this (in my head) is to use the main application to wait for an error signal through the local socket, and the updater can send the command through the local network. Another thing you should consider is that the updater should run in a separate Java process. If your main program simply creates a new Updater object, Updater will coexist with the main JVM program, which brings you back to the square.
I think the right thing here is to restart the application. Event, if you can update the jar at runtime, all kinds of errors may occur after versions of classes, different classes, different implementations, etc.
This issue has already been resolved by OSGi.
The real problem is not downloading the new version of jar. This can be done using your own class loader, which frees file locking. The real problem is how to handle instances of different versions of the same class .
Restarting omits this problem. If you really need different versions of jar in one application, use OSGi.
A typical way to do this is to write a separate update file that will be called by your main program when it sees the update. At this time, your main program can start the update in a new process and exit. The updater may wait for the main program to exit, download and copy the updated files, and restart the main program.