Dynamic Plugin Loading
Prev | Chapter 2. API Changes | Next

## Dynamic Plugin Loading

In jEdit 4.1 and earlier, plugins are always fully loaded at program startup, and unloaded at program shutdown. While the plugin loader and API was very simple as a result, this scheme had two main disadvantages:

- Having a large number of plugins generally slowed down jEdit startup, since many plugins performed a lot of lengthy initialization. Even if all plugins made their `start()` methods as quick as possible, there would still be the overhead of scanning the JAR files, loading the plugin classes, and so on.

- There was no way to reload plugins in a running jEdit instance. This made plugin development and use of the plugin manager a bit cumbersome.

Through a stroke of insight, one notices that the only functions called from most plugins' `start()` methods fall into two categories:

- Registration of virtual file systems, fold handlers, macro handlers, Console shells, SideKick parsers, ...

- Arbitriary initialization that only needs to be done when the plugin is first invoked by the user, and not at program startup.

jEdit 4.2 moves the former task out of the `start()` method and into a file within the JAR that can be parsed quickly. This allows the plugin core class to only be loaded, and its `start()` method called, only when the plugin is first invoked. Note that the `start()` method is always called from the event dispatch thread (or from the main thread if the GUI has not yet been loaded). Therefore you do not need to worry about thread-safety issues.

Also, plugins can now be loaded and unloaded at runtime.

Prev | Up | Next
BeanShell | Home | EditPlugin Class Changes