E4/Compatibility

This page is to collect input on how best to provide the backwards compatibility layer, what it needs to cover and hopefully identify some people who are willing to help work on the layer itself.

Warning: this page is under active constuction...results may change every time you hit 'refresh'...;-)

Design Goals

At the end of the day in order to be accepted as 'Eclipse' we must have a backwards compatibility story. We've committed to running a majority of existing 'API-clean' plug-ins. There are literally 1,000's of existing Eclipse components, all written against the current 3.x framework Extensions/API.

One of the main goals is to ensure that we don't dilute the pure E4 mechanisms in the effort to provide backwards compatibility. This means that the compatibility layer itself must be an optional component of an E4 install.

General Issues

• Bundle Loading - In many cases bundles will have compatibility requirements that must be satisfied before the bundle can even be loaded. For example, the current jdt.ui bundle fails to load because it's registering some colors on startup that are expected to be in the PreferenceStore (which isn't in E4 yet). This immediately precludes any use of its parts since createExecutableExtension needs to load the bundle first.

• Scoping issues - Part of the compatibility story will require that we provide code-compatible replacements for existing implementation classes (i.e. PlatformUI, ViewPart) while retaining existing implementations where possible. This will likely require some refactoring of the existing 3.X bundle/package structure to allow for a specific bundle containing all Class's for which a separate E4 implementation is desired.

• Listeners - One of the most complex parts of the existing code is the vast number of ways that clients can register to listen for changes in the environment. To further complicate matters the listener firing order counts so we'll have to maintain this order at least to some degree. This isn't just a maintenance of the order of the listeners in a particular list but in the order of firing of event from the different lists.

NOTE: Event ordering issues produce some of the most 'interesting' defects we get.

Self Hosting

Much of the compatibility layer will have to be in place in order to move the 'self hosting' story beyond the most naive implementation. If we can identify which elements )Views/Editors/Commands) of eclipse we need to properly self host we can then target the compatibility work towards making these available in an E4 Workbench.

• Self Hosting Elements
  • Need to have
    • At least one of the Resource views (Package Explorer, Project Explorer, Resource Navigator)
    • The CVS Repository View
    • The JDT editor

There are two main areas that will need support:

Extension Points

Providing backwards compatibility for the existing extension points means that the defined extension to the workbench appears and works in a manner appropriate to the intent of the extension.

(doc)

• Programmatic API (doc)

Documentation Reference

Extension Points Documentation

API Reference Documentation