Implementing dynamic plugins in Java

Question

I'd like to implement a dynamic plugin feature in a Java application. Ideally:

• The application would define an interface Plugin with a method like getCapabilities().
• A plugin would be a JAR pluginX.jar containing a class PluginXImpl implementing Plugin (and maybe some others).
• The user would put pluginX.jar in a special directory or set a configuration parameter pointing to it. The user should not necessarily have to include pluginX.jar in their classpath.
• The application would find PluginXImpl (maybe via the JAR manifest, maybe by reflection) and add it to a registry.
• The client could get an instance of PluginXImpl, e.g., by invoking a method like getPluginWithCapabilities("X"). The user should not necessarily have to know the name of the plugin.

I've got a sense I should be able to do this with peaberry, but I can't make any sense of the documentation. I've invested some time in learning Guice, so my preferred answer would not be "use Spring Dynamic Modules."

Can anybody give me a simple idea of how to go about doing this using Guice/peaberry, OSGi, or just plain Java?

Answer 1

This is actually quite easy using plain Java means:

Since you don't want the user to configure the classpath before starting the application, I would first create a URLClassLoader with an array of URLs to the files in your plugin directory. Use File.listFiles to find all plugin jars and then File.toURI().toURL() to get a URL to each file. You should pass the system classloader (ClassLoader.getSystemClassLoader()) as a parent to your URLClassLoader.

If the plugin jars contain a configuration file in META-INF/services as described in the API documentation for java.util.ServiceLoader, you can now use ServiceLoader.load(Plugin.class, myUrlClassLoader) to obatin a service loader for your Plugin interface and call iterator() on it to get instances of all configured Plugin implementations.

You still have to provide your own wrapper around this to filter plugin capabilites, but that shouldn't be too much trouble, I suppose.

Answer 2

OSGI would be fine if you want to replace the plugins during runtime i.g. for bugfixes in a 24/7 environment. I played a while with OSGI but it took too much time, because it wasn't a requirement, and you need a plan b if you remove a bundle.

My humble solution then was, providing a properties files with the class names of plugin descriptor classes and let the server call them to register (including quering their capabilities).

This is obvious suboptimal but I can't wait to read the accepted answer.

Answer 3

Any chance you can leverage the Service Provider Interface?

Answer 4

The best way to implement plug-ins with Guice is with Multibindings. The linked page goes into detail on how to use multibindings to host plugins.