Error running an SWT application about update4j HOT 8 CLOSED

I see what you mean. Currently, the update happens in the main thread and the launch is done in a new thread. You're proposing to reverse this setup.

Well, the default bootstrap is really here to get you quickly running your application without diving into the library details. You will most likely want to customize this behavior, in which case you can provide your own bootstrap.

from update4j.

If I'm not wrong, ConfigImpl.doLaunch launches the application in a thread, so using a custom bootstrap won't fix the issue if calls Config.launch. At least this should be fixed.
Maybe I can try to do the changes myself and send a pull request, I don't have a Mac to test so it may take some time.

from update4j.

Indeed you're right, but this is documented so changing this might break other people's projects.

Could you perhaps start SWT in the main thread before launching the business application?

You mentioned it only happens for --launchFirst; your above mentioned issue should happen in both launch types.

from update4j.

Yes, you are right, it should happen with both launch types, I started writing before realizing that doLaunch started another thread and forgot to edit.

I'm not sure how starting the application in the doLaunch thread would break other applications. It starts a thread and waits for it to finish, so anything calling it will block (as documented on Configuration.launch). Is there a reason to start a new thread and wait instead of just starting the application ?

I would avoid writing a dedicated bootstrap, the default is more than enough for my needs currently. Actually I would like to have an option to just check the presence of update.zip, apply the changes and launch the application, nothing else. I don't want any "under the hood" self-update, all updates should be user initiated (this is both because it is an experimental implementation for me, and because I don't like automatic updates in other software...).

from update4j.

The primary reason to start another thread is to keep the thread context class loader separated. It's very complex to explain but you could read about the class loading model in the docs.

Of course, nothing keeps you from forking and doing your own thing 😉.

from update4j.

Wrote a simple patch to get rid of the additional threads and seems it works well with SWT on MacOS.
Also no problems with Linux and Windows.

update4j_main_thread.patch.txt

Anyway, I think I'll go the fork way for my project.
As a side note, I started writing a maven-plugin to generate the config file, if you are interested.

from update4j.

Yes, I might be interested. If it solves a problem I'll add a reference to the README

from update4j.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from update4j.