I am developing Eclipse plugins. My plugins are calling MFC code through JNI. I found out that in Eclipse 4.4.2 the following change occurred - the plugins are now stopped by a thread called "Framework stop" - before they were stopped by the same thread that activated them, the main thread. Due to this change eclipse.exe and javaw.exe are not released correctly when eclipse exits (while my plugins are loaded).
Does anyone know if there is any setting to instruct Eclipse to use the main thread to stop the plugins ? Any documentation for this change in Eclipse ?
I'm unsure how you ensured that the bundles were started by the main thread. It certainly is possible they would be started by any thread. Especially if the bundles are lazy activated.
But also if the bundles use the default start level. Typically they would be installed by one thread, depending on what is installing them (EclipseStarter or p2), and started by another thread (the start-level thread) once the final start-level of the framework has been set.
To answer your question. The change of behavior was not documented because what thread starts and stops the bundles should not be considered API. The OSGi specification makes no guarantees in this regard. What did change in 4.4.x is the API that the Equinox launcher (EclipseStarter) uses to control the framework. Before it used some internal Equinox specific class that had a shutdown() method on it. This method would stop all the bundles synchronously on shutdown. EclipseStarter would do this from the main launching thread.
Now it uses the spec'ed interface org.osgi.framework.Framework and it calls the Framework.stop() method to shutdown the framework. This is an asynchronous operation.
Many thanks for your reply on this issue. I understand from your reply there's no way to ensure that a bundle is started and stopped by the same thread. I have couple of follow-up questions:
Were there any solutions proposed in the past for developers that needed such constraint for their bundles ? Or any solutions to ensure that some start-stop code is running from main thread ? I tried using IWorkbenchListener.postShutdown to call my prolematic JNI code - it worked ! It was called from the main thread and my javaw.exe and eclipse.exe were released successfully. Based on your reply, I probably did not test all possible load scenarios. I would be grateful if you could share a link for documentation about the complete list of load scenarios.
I tried also using either Display.getDefault().syncExec or Display.getDefault().asyncExec to call my JNI termination code to ensure it is running from the main thread. syncExec caused the application to block (deadlock with main thread ?) and asyncExec caused a JVM crash stating "EXCEPTION_ACCESS_VIOLATION". So, it seems that currently only the solution using IWorkbenchListener.postShutdown seems to work. However, based on what Thomas wrote above, I'm not sure if it will be always being called from the main thread. Is there any documentation stating that IWorkbenchListener.postShutdown is always being called from the main thread ? I'll be grateful for any information regarding this question. I also tried lazy loading my plugin, the start code was called from the main thread, so I currently was not able to reproduce a scenario where my JNI code is not initialized from the main thread. If anyone has link to a documentation for the complete set of scenarios for running Eclipse and loading plugins, I'll be grateful if you could share it here.
I would ask the Eclipse Platform forum about postShutdown 
I imagine this method must be called from the UI thread used for SWT. SWT also requires the main thread to be used for UI stuff. But you should confirm that with the platform.
For documentation how bundles are activated lazily you can have a look at the OSGi specification. But I will tell you that any thread that is executing code has the potential to define/load classes which may trigger a lazy activation. Similarly on stopping a bundle, the is OSGi API that allows anything to stop a bundle from any thread. In Eclipse bundles typically are never stopped until the platform is shutdown. And as you observed, in Luna this is not done in a separate thread for the start-level.
The last think I will mention is that I think somewhere in the workbench, or maybe SWT API there is a method (static?) you can call to execute a runnable on the UI thread. See https://www.eclipse.org/swt/faq.php#uithread