Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
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'...;-)
Contents
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
A significant portion 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.
Note that the 'self-hosting' environment outlined below is a fairly high target but let's be realistic. While we can write everything in a text editor we'd be so unproductive that we'd all sneak back to our beloved eclipse to do any real work (defeating the purpose of eating your own dog food).
What do we mean by 'self-hosting'?
This means that we'd be using E4's workbech to develop itself on a day-to-day basis. Over time it would become less and less necessary to resort to 'outside' tooling (legacy eclipse) to get our work done until we are simply using it as we currently do eclipse.
What do we need to self-host?
We're developers so we all know the drill...;-)
- check out what you want to work on
- write some code
- debug the code
- check it in
Pushing along the path towards self-hosting may prove to be an effective means to focus the compatibility efforts; simply taking something like the CVS Repositories view and providing whatever compatibility support it needs in order to come up will teach us a lot and move us along the path a fair ways. Then 'rinse and repeat' for the other components (JDT views...).
OK, we could likely live for a while using legacy eclipse to manage the CVS stuff and work directly against some 'local' projects (oh, that means that some concept of 'project' is needed, along with the builders...) even if we aren't using CVS.
On the other hand losing the JDT support would really cut back on productivity (it's a truly great java development environment). So perhaps we should focus on getting the JDT editor up. This is admittedly a large (huge?) bite to take first but may well be worth it. By the time it's running chances are that most of the other views...would be fairly simple.
The good news is that by the time we can host these parts we're probably most of the way towards supporting a large segment of all existing parts...
Note that we don't have to have everything working perfectly in order to self-host. For example menu items could all be enabled as long as the needed ones (i.e. Save) actually work.
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.
Some extensions are 'data only' (i.e. they define no 'executable'); they simply inject information into the workbench which is then used in some portion of the UI. The perspective's various 'shortcut' lists all fall into this category, they simply provide info that is used by the New/Import/Export wizards and the 'Show View' menu to populate the appropriate list. These should be relatively simple (they don't require bundle loading for example).
Some extensions may require either replacement or 'tooling' in order to be integrated into the E4 workbench UI since they are in conflict with some part of E4's architecture. For example the current 'themes' extension point overlaps with E4's CSS story in a way that may require some integration work to make an appropriate CSS style sheet from the legacy theme.
Finally come those extensions that provide the 'meat' of the current UI; Views, Editors and their related Commands structures. These all have at their core an 'executable extension' that implements a defined interface or extends a defined base class. In each case E4 will have to delegate to the compatibility layer to interact with the implementation classes in the correct manner (for example calling the (legacy) ViewPart's 'setFocus' method when the view activates).
Programmatic API
in addition to the extension points Eclipse also defines a number of programmatic API sets; some for use within the regular Eclipse IDE and others specifically for use with RCP apps.
First and foremost amongst these is 'PlatformUI', a singleton that provides access to APIs (generally through an interface) to various aspects of the workbench (it's active WorkbenchWindow/Page/Perspective...). Having a replacement for this is crucial since almost any non-naive Eclipse component is going to use PlatformUI in one way or another. Note that the replacement implementation will, by necessity, have to also provide E4-specific implementations of the interfaces that can be accessed through it.