Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "FAQ When does a plug-in get started?"
m |
|||
| Line 1: | Line 1: | ||
| − | A plug-in gets started when the user needs it. | + | 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. |
| − | 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 <i>declarative</i> section and a code section. The declarative part is contained in the <tt>plugin.xml</tt> 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. | To get down to specifics, a plug-in can be activated in three ways. | ||
| + | * If a plug-in contributes an <i>executable extension</i>, another plug-in may run it, causing the plug-in to be automatically loaded. For more details, read the API javadoc for <tt>IExecutableExtension</tt> in the <tt>org.eclipse.core.runtime</tt> package. | ||
| − | * If a plug-in | + | * 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()</tt>. This method returns a fully initialized plug-in instance. | ||
| + | In all these cases, if the plug-in contributes a runtime plug-in object (subclassing <tt>org.eclipse.core.runtime.Plugin</tt>), its class initializer, constructor, and <tt>startup</tt> method will be run before any other class in the plug-in gets loaded. Of course, if the plug-in’s constructor or <tt>startup</tt> 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 <tt>requires</tt> list will cause it to be activated before your plug-in. This is <i>not true</i>. Your plug-in may very well be loaded and used without plug-ins in your <tt>requires</tt> 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | 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 <tt>Plugin.startup</tt> method. Does the code in your <tt>startup</tt> 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 <tt>Plugin.startup</tt>. 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 <i>declarative</i> as much as possible. Keep in mind that extensions can contribute text strings, icons, and simple logic statements via <tt>plugin.xml</tt>, allowing you to defer or possibly completely avoid plug-in activation. | ||
== See Also: == | == See Also: == | ||
| + | [[FAQ What is the plug-in manifest file (plugin.xml)?]] | ||
| + | [[FAQ Can I activate my plug-in when the workbench starts?]] | ||
| − | + | {{Template:FAQ_Tagline}} | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Revision as of 05:03, 17 June 2006
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()</tt>. 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.
See Also:
FAQ What is the plug-in manifest file (plugin.xml)? FAQ Can I activate my plug-in when the workbench starts?
This FAQ was originally published in Official Eclipse 3.0 FAQs. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the Eclipse Public License v1.0.