- FAQ 94: What is a plug-in?
- FAQ 95: Do I use plugin or plug-in?
- FAQ 96: What is the plug-in manifest file (plugin.xml)?
- FAQ 97: How do I make my plug-in connect to other plug-ins?
- FAQ 98: What are extensions and extension points?
- FAQ 99: What is an extension point schema?
- FAQ 100: How do I find out more about a certain extension point?
- FAQ 101: When does a plug-in get started?
- FAQ 102: Where do plug-ins store their state?
- FAQ 103: How do I find out the install location of a plug-in?
- FAQ 104: What is the classpath of a plug-in?
- FAQ 105: How do I add a library to the classpath of a plug-in?
- FAQ 106: How can I share a JAR among various plug-ins?
- FAQ 107: How do I use the context class loader in Eclipse?
- FAQ 108: Why doesnt Eclipse play well with Xerces?
- FAQ 109: What is a plug-in fragment?
- FAQ 110: Can fragments be used to patch a plug-in?
- FAQ 111: What is a configuration?
- FAQ 112: How do I find out whether the Eclipse Platform is running?
- FAQ 113: Where does System.out and System.err output go?
- FAQ 114: How do I locate the owner plug-in from a given class?
- FAQ 115: How does OSGi and the new runtime affect me?
- FAQ 116: What is a dynamic plug-in?
- FAQ 117: How do I make my plug-in dynamic enabled?
- FAQ 118: How do I make my plug-in dynamic aware?
This chapter is from the book
This chapter is from the book
This chapter is from the book
FAQ 101: When does a plug-in get started?
A plug-in gets started when the user needs it. In UI design, an often cited rule is that the screen belongs to the user. A program should not make changes on the screen that the user didn’t somehow initiate. Making users feel that they are in control of what is happening builds their confidence in the UI and results in a much pleasanter user experience. This rule is followed by the Eclipse UI, but the underlying principle has been applied to a much broader scope. In Eclipse, one of the goals is to have the screen, the CPU, and the memory footprint belong to the user; that is, the CPU should not be doing things the user didn’t ask it to do, and memory should not be bloated with functions that the user may never need.
This principle is enforced in the Eclipse Platform through lazy plug-in activation. Plug-ins are activated only when their functionality has been explicitly invoked by the user. In theory, this results in a relatively small start-up time and a memory footprint that starts small and grows only as the user begins to invoke more and more functionality.
The extension point mechanism plays an important role in lazy activation. Each plug-in can be viewed as having a declarative section and a code section. The declarative part is contained in the plugin.xml file. This file is loaded into a registry when the platform starts up and so is always available, regardless of whether a plug-in has started. This allows the platform to present a plug-in’s functionality to the user without going through the expense of loading and activating the code segment. Thus, a plug-in can contribute menus, actions, icons, editors, and so on, without ever being loaded. If the user tries to run an action or open a UI element associated with that plug-in, only then will the code for that plug-in be loaded.
To get down to specifics, a plug-in can be activated in three ways.
-
If a plug-in contributes an executable extension, another plug-in may run it, causing the plug-in to be automatically loaded. For more details, read the API javadoc for IExecutableExtension in the org.eclipse.core.runtime package.
-
If a plug-in exports one of its libraries (JAR files), another plug-in can reference and instantiate its classes directly. Loading a class belonging to a plug-in causes it to be started automatically.
-
Finally, a plug-in can be activated explicitly, using the API method Platform.getPlugin(). This method returns a fully initialized plug-in instance.
In all these cases, if the plug-in contributes a runtime plug-in object (subclassing org.eclipse.core.runtime.Plugin), its class initializer, constructor, and startup method will be run before any other class in the plug-in gets loaded. Of course, if the plug-in’s constructor or startup method references any of its own classes, they will be loaded and, possibly, instantiated before the plug-in is fully initialized.
It is a common misconception that adding a plug-in to your requires list will cause it to be activated before your plug-in. This is not true. Your plug-in may very well be loaded and used without plug-ins in your requires list ever being started. Never assume that another plug-in has been started unless you know you have referenced one of its classes or executed one of its extensions.
To play along with the rule of lazy activation, plug-in writers should follow some general rules.
-
Do an absolute minimum of work in your Plugin.startup method. Does the code in your startup method need to be run immediately? Do you need to load those large in-memory structures right away? Consider deferring as much work as possible until it is needed.
-
Avoid referencing other plug-ins during your Plugin.startup. This can result in a sequence of cascading plug-in activations that ends up loading large amounts of unneeded code. Load other plug-ins—either through executable extensions or by referencing classes—only when you need them.
-
When defining extension points, make the extension declarative as much as possible. Keep in mind that extensions can contribute text strings, icons, and simple logic statements via plugin.xml, allowing you to defer or possibly completely avoid plug-in activation.
Note
FAQ 96 What is the plug-in manifest file (plugin.xml)?
FAQ 182 Can I activate my plug-in when the workbench starts?