As Eclipse uses OSGi to handle modules and bundles, and therefore should be able to hot-deploy them, why does it suggest to restart after installing a plugin “for changes to take effect”?
Has Eclipse hit some OSGi limitation, or is its architecture such that even with hot-deploy, it cannot guarantee that deployments went smoothly and hence takes the safest route by offering a restart?
3
The unfortunate reality is that once you have sufficiently interconnected modules, it is almost impossible to prove that all references to modules that you wish to unload will be removed in any circumstance. Many libraries and even core JDK classes will hold references to objects or classes for long periods of time, or even forever, and even a single stray reference will prevent the ClassLoader
that loaded a module from being garbage collected.
Such problems are very tedious to solve, hard to detect automatically, and are very easy to reintroduce.
This problem rears its ugly head also with redeployment of WAR
s in servlet containers such as Jetty or Tomcat.
Many developers choose a more pragmatic route and spend time developing new features and fixing bugs rather than ensuring that hot loading and unloading of code works 100% correctly. So Eclipse recommends that you restart whenever you reconfigure its plugins, since it cannot guarantee that all plugins that you download will hot load or unload correctly.
The Eclipse platform does support dynamically installing plugins without restarting. In the past this option was made available via an “Apply Now” option. Unfortunately for this to work properly the plugin itself also needs to support dynamic behavior. The large majority of Eclipse plugins out there are not dynamic themselves – they don’t clean up after themselves, and they don’t dynamically react to services or extensions being added/removed after they have started. Therefore the “Apply Now” button was sometimes jokingly referred to as the “I’m feeling lucky” button. Maybe it will work, but maybe some of the plugins currently installed won’t handle the dynamic change to the system.
In the end installing plugins is infrequent enough that a restart is the cleanest and safest approach. This is not so much an architectural limitation… making code fully dynamic is hard work in any application framework, and many tool writers clearly don’t think it is worth the investment.
Probably because they can’t force bundles to release service references, so it might be possible for one bundle to have a service reference to another that’s been updated or removed. That’s why they warn that not restarting can lead to unwanted behavior.