Eclipse Rich Client Platform UI
Proposed Approach

Last revised 16:30 EST November 7, 2003

The objective of the Eclipse Rich Client Platform (RCP) effort is to enable Eclipse to be used in a wide range of end-user applications that are not IDEs.

Our general approach is to factor out the generally useful portions of the existing Eclipse workbench into a generic Eclipse workbench. The generic workbench is still based on views, editors, and perspectives; however, it does not have any of the IDE-specific mechanisms, APIs, or extension points. The generic workbench is configurable so that key UI policy decisions, like whether the workbench window has a tool bar; these are provided by new APIs available to the designer of the application. The Eclipse IDE workbench is built atop the generic Eclipse workbench and uses these new APIs to impose particular policies that give it its distinctive IDE "personality". The generic workbench is located in a plug-in separate from the IDE workbench to allow applications to be built on top of the generic workbench alone, and not require any of the IDE-specific Eclipse plug-ins.

How do we go about finding the minimal set of plug-ins that will be needed in all RCP configurations?  The following table lists the plug-ins in the Eclipse Platform (2.1.1 Platform drop for Win32) and their sizes on disk:

It would be relatively straightforward to omit the following Eclipse Platform plug-ins from the minimal RCP configuration:

• Ant - org.apache.ant, org.eclipse.ant.core, org.eclipse.ui.externaltools
• Help implementation - org.eclipse.help.appserver, org.eclipse.help.ui (including org.eclipse.help.ui.win32), org.eclipse.help.webapp, org.apache.lucene, org.eclipse.tomcat
• Compare - org.eclipse.compare
• Debug - org.eclipse.debug.core. org.eclipse.debug.ui
• Team - org.eclipse.team.core, org.eclipse.team.ui, org.eclipse.team.cvs.core, org.eclipse.team.cvs.ui, org.eclipse.team.cvs.ssh
• UI version check - org.eclipse.ui.versioncheck
• Update UI - org.eclipse.update.ui, org.eclipse.update.ui.forms
• Documentation - org.eclipse.platform.doc.user
• Feature plug-in - org.eclipse.platform

The rest of the Eclipse Platform plug-ins would need to be included in the minimal RCP configuration:

• Runtime - org.apache.xerces (1.20 MB), org.eclipse.core.boot (0.22 MB), org.eclipse.core.runtime (0.25 MB) - total 1.67 MB.
  The runtime is essential.
• UI - org.eclipse.swt (1.23 MB), org.eclipse.jface (0.43 MB), org.eclipse.ui (0.21 MB), org.eclipse.ui.workbench (2.08 MB), org.eclipse.ui.views (0.32  MB) - total 4.27 MB.
  The org.eclipse.ui plug-in re-exports the API from these plug-ins. Hence none can be omitted.
• Resources - org.eclipse.core.resources (0.61 MB).
  There are various places in the workbench API and implementation that depend on classes provided by the resources plug-in.
• Text editors - org.eclipse.text (0.07 MB), org.eclipse.jface.text (0.34 MB), org.eclipse.ui.workbench.texteditor (0.23 MB), org.eclipse.ui.editors (0.10 MB) - total 0.74 MB
  The org.eclipse.ui plug-in re-exports the API from these plug-ins.
• Help - org.eclipse.help (0.26 MB).
  There are a few places in the workbench API that depend on API provided by the help plug-in.
• Update Core - org.eclipse.update.core (0.39 MB).
  This is needed for plug-in "reconciliation" which happens when a newly-installed Eclipse is first started. (This is a "core" dependency, rather than a "UI" one.)

To maintain binary compatibility, we would add the new application workbench APIs into the existing UI plug-in (org.eclipse.ui and its buddy org.eclipse.ui.workbench have most of the code). We would create a new plug-in for the IDE (org.eclipse.ui.ide). This new plug-in would contain the implementation of the IDE application, although much of the IDE would still be implemented by code within the existing org.eclipse.ui.workbench plug-in, since that it where it is now. The new plug-in would make IDE-specific contributions to the workbench extension points. The new plug-in would not be included in the minimal RCP configuration, ensuring that the generic workbench does not include IDE-specific perspectives, views, actions, etc.

This approach would provide binary compatibility of 3.0 plug-ins over 2.1, while allowing us to introduce new mechanisms so that non-IDE applications could be built on the RCP base. This approach, however, has three shortcomings:

• It continues with the workspace as the workbench's underlying data model. For the workbench to be generically useful in a wide range of applications, we need to rid it of all built-in biases towards the workspace.
• API clutter - The IDE-specific API and extension points of the existing workbench, including the resources API and existing IDE-specific actions, dialogs, etc., are included in the minimal RCP configuration. Applications that have no need for these IDE-specific things must ignore them, and tell developers writing plug-ins for those applications to ignore them as well. It would be less confusing if IDE-specific API and extension points were omitted from applications that have no need for them.
• Bloated disk footprint - The minimum RCP configuration includes plug-ins that provide little value to many applications, namely: resources (0.61 MB), and text editors (0.74 MB), and the standard views (0.23 MB). A portion of the org.eclipse.ui.workbench plug-ins is resource- and IDE-specific; the size of this portion is estimated to be 0.20 MB. The minimum RCP configuration starts at 8.04 MB (about 1/3 the size of the Platform drop). The applications would be smaller if the minimum RCP configuration did not include plug-ins and code that are not used.

As the Eclipse workbench grows in future releases with new APIs and extension points, it is likely that the API clutter and disk bloat will also increase because it will not always be possible to avoid putting new IDE-specific pieces into plug-ins in the RCP base. So both of these problems will tend to get worse as Eclipse evolves.

These shortcomings are significant enough to warrant considering breaking API binary compatibility in order to address them.

Severing ties to resources (and the IDE-specific dialogs, etc.) would reduce the minimum RCP configuration by about 0.8 MB. Severing the ties to text editors would reduce it by 0.74 MB; to the standard views, by another 0.32 MB. All this would reduce the minimal RCP configuration from 8.04 MB to about 6.1 MB. Of that 6.1 MB, 2.06 MB is the runtime, 0.26 MB is help, and the rest (3.75 MB) is the workbench UI. There are no straightforward ways to reduce the size of the workbench UI further, so 6.1 MB can be considered a lower bound on the size of the minimum RCP configuration (obviously, this bound changes if the size of the Platform runtime changes, which is likely due to 3.0 efforts on other fronts).

Severing ties to text editors is quite simple (most of the hard work was already done in 2.1). The only breaking API changes required to achieve this are:

• Move existing text editor-specific extension points from org.eclipse.ui to one of the text editor-specific plug-ins.
• Change org.eclipse.ui so that it neither depends on, nor re-exports the API of, the various text editor plug-ins. (Plug-ins that need text editors will need to prereq them directly.)

Porting in light of this kind of breakage is straightforward: it involves changing existing plug-in manifest files; plug-in code does not need to be changed or recompiled.

Severing ties to resource- and IDE-specific things is only a bit more work. The breaking API changes required to achieve this are:

• Move existing IDE-specific extension points from org.eclipse.ui plug-in to the new org.eclipse.ui.ide plug-in.
• Move existing IDE-specific API classes from org.eclipse.ui plug-in (and friends) to the new org.eclipse.ui.ide plug-in.
• Change org.eclipse.ui so that it neither depends on, nor re-exports the API of, the views plug-in. (Plug-ins that need standard views will need to prereq it directly.)
• Remove existing IDE-specific API methods from remaining classes in org.eclipse.ui plug-in (and friends), and provide back-fill API capability (somewhere) so that existing clients can port.

The first 3 kinds of changes are similar to the above: porting involves changing existing plug-in manifest files. The last kind of breakage involves changing code. By design, the Eclipse workbench APIs are generic and independent of particular editors and views, and the underlying data model is largely independent of the workspace. Unfortunately, a small number of unwanted dependencies crept in late in the 1.0 release. There are a handful of API methods that would need to be removed in order to make the workbench API completely generic and free from IDE-specific influences:

• Package org.eclipse.ui
  • Interface IWorkbench
    • public IMarkerHelpRegistry getMarkerHelpRegistry() - deleted method
  • Interface IWorkbenchPage
    • public IEditorPart openEditor(IFile input) - deleted method
    • public IEditorPart openEditor(IFile input, String editorID) - deleted method
    • public IEditorPart openEditor(IFile input, String editorID, boolean activate) - deleted method
    • public IEditorPart openEditor(IMarker marker) - deleted method
    • public IEditorPart openEditor(IMarker marker, boolean activate) - deleted method
    • public void openSystemEditor(IFile input) - deleted method
  • Interface IEditorPart
    • public void gotoMarker(IMarker marker) - deleted method
    • Change also affects other API classes that implement IEditorPart: org.eclipse.ui.part.EditorPart, MultiEditor, MultiPageEditor, MultiPageEditorPart; org.eclipse.ui.texteditor.AbstractTextEditor and StatusTextEditor
  • Interface IEditorLauncher
    • public void open(IFile) replaced by public void open(IPath)
  • Interface IEditorRegistry
    • public IEditorDescriptor getDefaultEditor(IFile file) - deleted method
    • public void setDefaultEditor(IFile file, String editorId) - deleted method
    • public ImageDescriptor getImageDescriptor(IFile file) - deleted method
    • public IEditorDescriptor getDefaultEditor() - deprecated method
  • Interface ISharedImages
    • various IDE-specific constant fields deprecated
  • Interface IWorkbenchActionConstants
    • various IDE-specific constant fields deprecated
  • Interface IWorkbenchPreferenceConstants
    • various IDE-specific constant fields deprecated
  • Interface IContributorResourceAdapter
    • public IResource getAdaptedResource(IAdaptable) replaced by public Object getAdaptedResource(IAdaptable)
• Package org.eclipse.ui.help
  • Class WorkbenchHelp
    • public static IHelp getHelpSupport() - deprecated method
• Package org.eclipse.help
  • Interface IHelp - deprecated interface

We also believe that the changes required to port existing plug-ins will be straightforward. Most of the method changes have to do with opening editors; none of the method are in particularly high-traffic parts of the API. So it is conceivable that some existing plug-ins will require no code changes. Changes to plug-in manifest files are more likely.

This modest amount of breakage is all that would be required to both eliminate the API clutter of IDE-specific elements and reduce the disk footprint of the RCP configuration to the practical minimum. Somewhat perversely, the damage from these changes only befalls existing customers of the Eclipse IDE (there are no Eclipse RCP customers to break yet). To existing IDE customers, the RCP is orthogonal to their direct interests. So they should not be expected to be particularly sympathetic to changes which can be seen as netting them nothing. The benefits of the breakage accrue to the RCP customers; the pain, to existing IDE customers.

It comes down to this question: in the big Eclipse picture, would the long terms gains of making these breaking changes outweigh the short term pain to existing clients?

We think so. We believe that these breaking changes will lead to a significantly cleaner and smaller Eclipse RCP, which will provide the best possible starting point for growing a future base of applications based on the Eclipse RCP, including the Eclipse IDE. We therefore advocate this second approach, rather than the first one which would preserve binary compatibility but would result in a less than ideal starting point for the Eclipse RCP.

Other approaches

For the sake of completeness, here are the alternative approaches to minimizing breakage that we considered but rejected.

Split API interfaces into generic interfaces with resource-specific subinterfaces

We considered splitting API interfaces into a generic interface with a resource-specific subinterface. For example, we considered introducing the interface IGenericWorkbenchPage and changing IWorkbenchPage to be a subclass of it; most of the existing methods would remain on IGenericWorkbenchPage, and IWorkbenchPage would have only the resource-specific openEditor methods. We quickly concluded that this would not be very tasty because of page listeners with methods like IPageListener.pageActivated(IWorkbenchPage) which would now need to accept IGenericWorkbenchPage; adding such a method to the IPageListener interface would break binary compatibility because clients implement this interface. This would force us to instead create of a new interface, IGenericPageListener, and a new set of methods on IGenericWorkbenchPage for adding and removing these listeners. This ripple effect would duplicate a lot of the existing workbench API interfaces and methods, making the API more bloated for everyone. So we abandoned this approach.

Retain dependence on org.eclipse.core.resources for API compatibility purposes only

We considered leaving the org.eclipse.core.resources plug-in as a part of the minimal configuration, and allowing the generic workbench pre-req it. We could do this and still rid the workbench implementation of the assumption that the workspace is the underlying data model. This would eliminate the API breakage due to removing the resources plug-in as a prereq of org.eclipse.ui. However, this arrangement means that there is still the risk that resource dependencies will creep back in (as they did in the past), and that the code for the org.eclipse.core.resources plug-in (0.61 MB) is still in the base configuration. The footprint matter could be addressed by providing a dummy org.eclipse.core.resources plug-in to be used in configurations where resources are not needed. The code JAR for this plug-in would contain dummy declarations for the minimal set of API interfaces and classes needed to satisfy the class loader when loading API from the org.eclipse.ui plug-in. While this approach would have a minimal footprint, it was rejected because of the general complications and myriad possibilities for confusion surrounding this dummy plug-in (which would need to share the plug-in id and version id with the real plug-in but have different contents), and still runs the risk that resource dependencies will creep back.