Community
Participate
Working Groups
Looking at the code in org.eclipse.ui.internal.Workbench.cancelEarlyStartup() it references https://bugs.eclipse.org/bugs/show_bug.cgi?id=94537 to explain why shutdown doesn't wait for the early start job(s) to complete. It's a valid concern that deadlock should be prevented and that such a situation is definitely possible. That being said, this comment is no longer valid: https://bugs.eclipse.org/bugs/show_bug.cgi?id=94537#c16 I.e., it is no longer "okay or better" to log errors because logged errors are reported as problems against the framework involved. For example, clients of the IStartup API end up with problem reports like this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=514895 In the end, the client can do nothing to prevent such problems but can end up with a plethora of different problem reports, none of which can be reproduced because the behavior depends on the subtle timing of shutdown and early start thread execution. To me this seems fundamentally broken/unacceptable. The IStartup API provides no access to a progress monitor, so I can't detect that I should abort processing. Even the workbench itself might disappear while the early start thread is running, so it's no longer safe to do anything without "class not found" exceptions or various other exceptions. I think the idea from this comment would be a significant improvement: https://bugs.eclipse.org/bugs/show_bug.cgi?id=94537#c15 I.e., waiting for a short time for early start threads/jobs to terminate. Perhaps with the move to Java 8, the IStartup API could include a default method that takes a progress monitor as an argument so that clients could be informed when the early startup is being canceled...
*** Bug 514895 has been marked as a duplicate of this bug. ***
*** Bug 514966 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Problems don't go away just because they are ignored.
Could you provide a Gerrit to add a progress monitor, Ed?
Probably not in the foreseeable future. :-( I recall this problem well though, and effectively all hell breaks loose in the running job because bundles are being shutdown destroying their state so nothing works as expected.
