3.1. Structural Overview
Eclipse isn't a single monolithic program, but rather a small kernel called a plug-in loader surrounded by hundreds (and potentially thousands) of plug-ins (see Figure 3-1) of which the Favorites example plug-in is one. Each plug-in may rely on services provided by another plug-in, and each may in turn provide services on which yet other plug-ins may rely.
Figure 3-1. Eclipse plug-in structure.
An example of how plug-ins depend on one another.
This modular design lends itself to discrete chunks of functionality that can be more readily reused to build applications not envisioned by Eclipse's original developers.
3.1.1. Plug-in structure
The behavior of every plug-in is in code, yet the dependencies and services of a plug-in (see Section 2.3.1, The Plug-in manifests, on page 71) are declared in the MANIFEST.MF and plugin.xml files (see Figure 3-2). This structure facilitates lazy-loading of plug-in code on an as-needed basis, thus reducing both the startup time and the memory footprint of Eclipse.
This is an example of how a new extension is declared in the plug-in manifest with lines highlighting how the plug-in manifest references various plug-in artifacts.
On startup, the plug-in loader scans the MANIFEST.MF and plugin.xml files for each plug-in and then builds a structure containing this information. This structure takes up some memory, but it allows the loader to find a required plug-in much more quickly, and it takes up a lot less space than loading all the code from all the plug-ins all the time.
Plug-ins Are Loaded But Not Unloaded In Eclipse 3.1, plug-ins are loaded lazily during a session but not unloaded, causing the memory footprint to grow as the user requests more functionality. In future versions of Eclipse, this issue may be addressed by unloading plug-ins when they are no longer required (see eclipse.org/equinox; and for more specifics on deactivating plug-ins see dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/ equinoxhome/dynamicPlugins/deactivatingPlugins.html).
The Eclipse IDE displays and modifies files located in a workspace. The workspace is a directory hierarchy containing both user files such as projects, source code, and so on, and plug-in state information such as preferences (see Section 3.4.4, Plug-in preferences, on page 116). The plug-in state information located in the workspace directory hierarchy is associated only with that workspace, yet the Eclipse IDE, its plug-ins, the plug-in static resources (see Section 3.4.3, Static plug-in resources, on page 115) and plug-in configuration files (see Section 3.4.5, Plug-in configuration files, on page 116) are shared by multiple workspaces.