In the past Eclipse has proven somewhat sensitive to concurrency issues in and around classloading and plugin activation. Great care has been taken in crafting the Eclipse classloader code to avoid conflicts as best as possible. While the move to OSGi will not particularly help or hinder this issue it will change some ordering and timing characteristics and so indirectly expose new or existing concurrency problems.
Analysis: The risk/impact here is hard to quantify. The current implementation is quite liberal with it synchronization scopes. This should be tightened so as to minimize the chance of lock conflict. Otherwise there is nothing inherently limiting about the OSGi classloading structure that would prevent at least equivalent concurrency behaviour.
Current build structures (e.g., PDE, custom builds done by product teams, ...) are based on plugins and features. While the new runtime supports plugins and features, it is bundle based. To support existing build structures we (and other bundle developers) must take care to include plugin.xml files for all bundles.
Analysis: If we maintain the plugin.xml content, there should be no impact to build mechanisms.
org.eclipse.ant.ui: Changed to use getEntry() instead of getResources() to access resource in the root of a plugin (i.e., not on the plugin's classpath). This change can likely be removed after deeper investigation of the why it works in standard Eclipse.
org.eclipse.core.resources: Remove minor test of classloader in an Stats class.
org.eclipse.help: Help contributes two URL stream handlers and so is subject to the breakage described above. The help: URL was changed to subclass AbstractURLStreamHandlerService. The JDNI URL contribution from Tomcat was changed to contribute a new subclass which implements URLStreamHandlerService. This subclass is basically a copy of AbstractURLStreamHandlerService.
Help also makes use of the implicit correlation betweek IPlugin* types and Plugin*Model types. This was updated accordingly.
org.eclipse.pde.core: PDE attempts to make use of the live (development environment) registry when creating a model of its target. This is lieu of building the model by parsing the plugins (i.e., it is an optimization). In doing this they cast from IPluginDescriptor to PluginDescriptorModel. As discussed, this is not API. Supporting this in a compatibility layer would be costly. Alternatively, PDE could remove the optimization and build the model by parsing the plugins. Note that they already have this code for use in other scenarios.
org.eclipse.ui.workbench.texteditor / org.eclipse.ui.editors / org.eclipse.jface.text / org.eclipse.text: These plugins previously split some packages. Since this is not supported, the relevant packages were consolidated.
org.eclipse.ui: Move the plugin class into the workbench plugin to resolve project circularity issue.
org.eclipse.ui.workbench: Remove reference to BootLoader in 1.0 backward compatibility related code (due to the , reference in Bootloader somewhere else