Plugin support

Thread view:

Nuno - 12 Jun 2007 14:48 GMT

Hello to all,

I'm new on java but i'm old on c++, and i'm now developing in java.

And i want to built a solution in java that implements the normal
logic of plugins in windows. That is a list of dll files in a
predefined folder and a program that loads each dll in the startup
process, and the rest is history... all the dll's implement the same
interface bla bla bla :)

And now i want to know what is the best solution to do the same thing
but in java environment. I've already tested the ClassLoader object in
java and it works fine to load a certain package, example:

String classdir = "file:/D:/tmpimp/java/tests/workspace/
com.teste.plugin/";
String classname = "com.teste.Math";

try
{
    ClassLoader loader = new URLClassLoader(new URL[] { new
URL(classdir) });
    Class c = loader.loadClass(classname);
    IMath o = (IMath) c.newInstance();

    int a = 1;
    int b = 2;
    int result = o.add(a, b);

    String.format("%d + %d = %d", a, b, result));
}
catch (Exception ex)
{
    System.out.println(ex.toString());
}

My question is to know witch is the best way to do this, the plugin
thing, and if this is a good way (with the ClassLoader object) then
what is the best way to find the packages in the file system, is using
a xml file or read a predetermine folder with all the packages.

Thanks
Nuno

Reply to this Message

Arne Vajhøj - 17 Jun 2007 00:12 GMT

> Hello to all,
>
[quoted text clipped - 20 lines]
> Class c = loader.loadClass(classname);
> IMath o = (IMath) c.newInstance();

> My question is to know witch is the best way to do this, the plugin
> thing, and if this is a good way (with the ClassLoader object) then
> what is the best way to find the packages in the file system, is using
> a xml file or read a predetermine folder with all the packages.

There are some variations, but this is the Java way of doing it.

Note that you only need your own classloader if you need unload
the classes or have multiple classes with the same name.

Object o = Class.forName(classname).newInstance();

will load using standard classloader.

Arne

Reply to this Message

Twisted - 17 Jun 2007 04:37 GMT

On Jun 16, 7:12 pm, Arne Vajh?j <a...@vajhoej.dk> wrote:

> There are some variations, but this is the Java way of doing it.
>
[quoted text clipped - 4 lines]
>
> will load using standard classloader.

I'm not sure you need to muck around with explicit classloader use or
reflection at all. Suppose a plugin is packaged as two files, a .class
and a .template file, with the .class the obvious -- a class file, for
a class implementing your Plugin interface. The .template file would
be a serialized instance of the class, and the interface would specify
instance methods.

The .class is in the classpath of the app (probably because a Plugins
directory is in the classpath of the app). At runtime, the app uses
File and other java.io tools to enumerate the .template files and
ObjectInputStream to get copies in RAM. Then it casts them to Plugin
and invokes instance methods. These objects can be factories for
document types the plugin supports, or they can be codecs whose
instance methods encode and decode streams, or ... the sky is the
limit.

The closest to reflection this comes, besides the reflection that goes
on under the hood with serialization, is when you cast the Object to a
Plugin and pray. :)

(Obviously you'd want to trap and recover from some exceptions during
plugin-loading, and log failed plugin loads in some way, while
ignoring only the failed ones. IOException, ClassCastException, and
ClassNotFoundException are the obvious ones, the latter caused if
someone installs only the .template file of a pair...)

Reply to this Message

Carsten Ringe - 17 Jun 2007 10:00 GMT

>> There are some variations, but this is the Java way of doing it.
>>
[quoted text clipped - 4 lines]
>>
>> will load using standard classloader.

There is another way to do plugins. Take a look at
http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider
to see an example. It's a nice way to find plugins even on runtime, so
users can just drop another plugin into the proper directory and rerun
the plugin management algorithm to start using it.

Carsten

Reply to this Message

Twisted - 17 Jun 2007 21:57 GMT

> > On Jun 16, 7:12 pm, Arne Vajh?j <a...@vajhoej.dk> wrote:
> >> There are some variations, but this is the Java way of doing it.
[quoted text clipped - 10 lines]
> users can just drop another plugin into the proper directory and rerun
> the plugin management algorithm to start using it.

Like most of them, but unlike mine, this seems to require a zero-
argument constructor in the class. :)
(Mine actually may require more than just a single .class file and
a .template mind you -- in the specific case of an abstract factory
there's likely to be additional .class files in the bundle. I'm not
sure how you'd detect missing dependencies and reject the plugin
immediately instead of flaming out with NoClassDefFoundError later on
trying to use the plugin, in case additional .class files were
required and not all of them were present. Perhaps the Plugin
interface would specify a "selfTest()" method that would try to access
all of the dependencies and throw a nicer exception if it caught
NoClassDefFoundError in the attempt. Or an instance of each class
would be in the .template file, and the plugin loader would try to
read everything in the ObjectInputStream though only keep the first
Object it saw. Or it would try to cast them all to Plugin, keep all of
the ones that made it through that filter, and complain if the number
of these was zero...allowing a plugin bundle with multiple points of
interface.)

Reply to this Message

Plugin support

Free Magazines