Auto-update of native application bundles
igor.nekrestyanov at oracle.com
Mon Jun 18 15:58:22 PDT 2012
On 6/18/12 3:31 PM, Daniel Zwolenski wrote:
> In your proposal the classpath is based on what is in the 'app'
directory, so if v1 and v2 were there at the same time they would both
get included on the classpath.
It is embedded java launcher that is part of main jar that decides what
needs to be taken.
Not everything in the app folder is used.
Anyway, here is one possible scenario (it may be somewhat different
depending on update type):
1. Application is running, update detected
2. Update is loaded in background, no UI is shown
3. Full application image is built in the temp folder (including
4. User is prompted to update and relaunch
5. If he agrees:
- application exits
- (optionally) UAC is shown for "swap" program
- "swap" program renames existing app folder
- moves new image in place of old app
- launches new version of application
- then cleanup old image
"move" is fast operation as long as we are on the same drive. No or
little UI is needed ("rename" will take 1-2 seconds at most?).
And if it is needed then in most of cases default UI should suffice.
It is possible to make it more complex and allow to customize this part
of UI but would be good to see if there is a need to do this.
E.g. we can put another app folder in the application directory and have
package.cfg to mention which one is active.
> The result is that in my POC the new jars can be copied in while the
old app is running, whereas in yours it can't. So in my POC the java GUI
can show progress and success/error, whereas in yours the java GUI will
have to be killed before the copy starts so the progress and
success/error will have to be shown in a hard coded native UI.
So, what if update need to update java.exe or and of dlls or
Have a different UI?
How do you elevate permissions to be able to copy files to Program Files?
Does it mean user application will run with full admin permissions?
More information about the openjfx-dev