plugins, api and classloaders

[ittay.dror]

Hi,

Assume I have an application that can load plugins.

I want a plugin to be able to use an API I provide, and nothing more.
How do I do that?

More detailed, I have an interface MyApi, implemented by MyApiImpl, and
a class MyPlugin loaded into my application. How can I make it
recognize MyApi, but not MyApiImpl? It has to work with MyApi
interface, but the object it links with is MyApiImpl. I want to acheive
this with class loaders, not public/private/package protection.
Thanx,
Ittay

 

[John C. Bollinger]

Assume I have an application that can load plugins.

I want a plugin to be able to use an API I provide, and nothing more.
How do I do that?

More detailed, I have an interface MyApi, implemented by MyApiImpl, and
a class MyPlugin loaded into my application. How can I make it
recognize MyApi, but not MyApiImpl? It has to work with MyApi
interface, but the object it links with is MyApiImpl. I want to acheive
this with class loaders, not public/private/package protection.

Plugins are required to implement something like this interface:

public interface Plugin {
void init(PluginConfig config);
<choose return type> doSomething(<choose argument type> arg);
}

Your application provides this interface (or perhaps just uses MyApi in
its place):

public interface PluginConfig {
MyApi getHostApi();
// perhaps other methods
}

and uses instances of it to initialize plugins. You make MyApiImpl
package-private, so that the plugin couldn't downcast even if it knew
the name of the implementation class.

None of this requires explicit reference to ClassLoaders, and I'm having
trouble seeing just how a ClassLoader could be used to achieve the kind
of protection you're talking about. ClassLoaders do have other uses
relative to plugins, however; in particular, careful use of a
ClassLoader to load a plugin can make it feasible to dynamically unload
/ replace it during program execution. By means of ClassLoaders you may
also be able to protect plugins from interference by other plugins
(somewhat).


John Bollinger
(e-mail address removed)

 

[ittay.dror]

assume i have a class Foo, internal to my system, that I wish plugin
writers will not have access to. what prevents a plugin writer to
access it?

 

[John C. Bollinger]

assume i have a class Foo, internal to my system, that I wish plugin
writers will not have access to. what prevents a plugin writer to
access it?

Make it package-private. If you're really worried about it then also
seal the package in its jar (see Jar documentation and tutorial for
that) to prevent the plugin writer from defining additional classes in
that package.

Depending on how (and whether) Foo is used by plugins (including
indirect use by objects passed to or manipulated by plugins) you _might_
be able to play ClassLoader / classpath games to completely hide Foo,
but this is a high-maintenance approach that I cannot really recommend.