Auto-update of native application bundles

Igor Nekrestyanov igor.nekrestyanov at
Mon Jun 18 15:03:37 PDT 2012

On 6/18/12 4:37 AM, Daniel Zwolenski wrote:
> One niggling thing for me: how will your solution update itself while it is running? In my POC the new and old versions coexist for a time to get around the file locking issue but in yours there can be only one version.
I think to large extent it is the same approach.

If we deal with patch or .zip-like archive we build app image elsewhere 
and then run "swap" utility from new image.
"Image" may be cleaned right the way or next time application is 
launched and AU code will detect image is the same as one we have installed.

It update package is actual installer (like msi) then i expect update 
driver should request application to exit and fork "msiexec" process.
Or fork "install utility" that needs to be copied outside of 
installation folder and can present custom progress dialogs whilst 
update is installed.
> Do you intend for the actual 'installation' to happen outside of the app using a native UI to show progress and success/error message or do you have some other trick in mind to update the jre while it is running?

> Also the 'full' updates could always exclude the JRE if Oracle released JRE zip files that the updater could download from (based on a version specified in the update bundle). I don't suppose there's any chance of legals letting this happen?
I do not know answer to this but it seems safer to not depend on 
something unknown.
If we will encounter opportunity to take shortcut in the future we can 
always take it.

> On 18/06/2012, at 2:54 PM, Igor Nekrestyanov<igor.nekrestyanov at>  wrote:
>> On 6/17/12 9:32 PM, Daniel Zwolenski wrote:
>>> I think I understand but please clarify any of the below if I got it wrong.
>>> Would it be correct to say that the main difference is that in your proposal you are working out the 'delta' update at compile/packaging time, whereas in my solution the app works out the 'delta' at runtime when an upgrade is requested. Assuming this is right, then:
>>> Because you are working deltas out at compile time you can bundle the updates into a single image file and avoid having an app-profile. In my solution I need everything extracted on the server with an app-profile so the app can work out the diff in jar versions at runtime. Your solution is definitely nicer on this front.
>>> On the other hand, because I work deltas out on the fly I don't need 'delta' image files and any old version can always update to the latest without downloading the full bundle even though no 'delta' file exist. In your solution we have multiple deltas to maintain and the more versions you have the more deltas you have to maintain (or not use deltas, resulting in larger downloads). If a delta is not available for a specific older version, then the app will have to download the full update and install this.
>> Yes, process wise this is correct (there are other differences caused by above, e.g. single file, no way you may get components signed by different certs, etc.).
>> Example is correct too, some size overhead is expected but if we can get bundle size down with better compression methods/etc then difference will be not that big.
>> My expectation is that appropriate compression techniques can get size can be down to 25Mb for Ensemble. And once subsetting of JRE will be easier
>> (technically and legaly) it could probably get down to 15Mb or so.
>> Few clarifications on the example:
>> 1. In step 2 and 3 if all of older versions of app use same JRE then we can use "reduced" version of ful update that updates everything but runtime folder
>>      This can cut download size if it is an issue
>> 2. Full image for update may be the same as an app.
>>      E.g. we are currently installing same .dmg for JRE on Mac and you certainly can do silent installation with .msi
>> 3. The way to get full app image to compare against is not fixed.
>>      For example, you can save .zip of 1.0 version when you built 1.0, or install and zip image before you are ready to ship new version,
>>       or even manually provide list of files to include into update.
>> 4. Based on feedback i saw from Sparkle users and Oracle's use of AU for JRE keeping lots of delta's is not required.
>>      Interestingly delta's are often used not to improve user's time to update but to reduce server load.
>> Another point to consider is that use of single "update package" seem to be the way many other native update systems are implemented
>> (based on what i saw, clearly i am not familiar with all of them).
>> -igor

More information about the openjfx-dev mailing list