Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Plugin architectures

Reply
Thread Tools

Plugin architectures

 
 
Ross
Guest
Posts: n/a
 
      10-05-2009
What are the best strategies for creating a Java application with a
plugin architecture.

My current plan is to have a directory of plugins, to read the files
manually, use ClassLoader.defineClass to create the class file,
Class.newInstance() to make one, and of course a number of interfaces
that plugins can implement, one for each plugin type.

Are there any better strategies that people would recommend? I don't
want to add the plugin directory to the classpath, as that would make
installation of the software more tricky than just putting a .jar file
somewhere and double clicking on it.
 
Reply With Quote
 
 
 
 
markspace
Guest
Posts: n/a
 
      10-05-2009
Ross wrote:
> What are the best strategies for creating a Java application with a
> plugin architecture.
>
> My current plan is to have a directory of plugins, to read the files
> manually, use ClassLoader.defineClass to create the class file,
> Class.newInstance() to make one, and of course a number of interfaces
> that plugins can implement, one for each plugin type.
>
> Are there any better strategies that people would recommend? I don't
> want to add the plugin directory to the classpath, as that would make
> installation of the software more tricky than just putting a .jar file
> somewhere and double clicking on it.



If you are using a Jar file, it wouldn't look at the class path anyway.
You have to set the Class-path property in the manifest file of the
Jar file to change the class path of a Jar.

If you add "." to the class path on the manifest, then the regular old
class loader will look in the Jar's home directory for resources, and
classes. If you add "plugin" (I don't think a / is required, although
it might be), the class loader will also look in a directory of the same
name in the home directory of the Jar file.

You may have to fuss around a bit to get Jars loaded instead of loose
classes, and to devise a good naming scheme that works for you and isn't
too hard on your clients. I haven't actually implemented such a thing
so I can't really offer any advice.

 
Reply With Quote
 
 
 
 
Ross
Guest
Posts: n/a
 
      10-05-2009
On Oct 5, 5:16 pm, markspace <(E-Mail Removed)> wrote:=
> If you are using a Jar file, it wouldn't look at the class path anyway.
> You have to set the Class-path property in the manifest file of the
> Jar file to change the class path of a Jar.
>
> If you add "." to the class path on the manifest, then the regular old
> class loader will look in the Jar's home directory for resources, and
> classes. If you add "plugin" (I don't think a / is required, although
> it might be), the class loader will also look in a directory of the same
> name in the home directory of the Jar file.
>
> You may have to fuss around a bit to get Jars loaded instead of loose
> classes, and to devise a good naming scheme that works for you and isn't
> too hard on your clients. I haven't actually implemented such a thing
> so I can't really offer any advice.


That's an interesting way of doing it. I think I'm going to try both
and then choose the best solution. I've never set a classpath in a
manifest file, I really should do. There's a number of jar related
functions I've never gotten around to trying, e.g. storing images and
other resources in jar files.
 
Reply With Quote
 
John B. Matthews
Guest
Posts: n/a
 
      10-05-2009
In article
<(E-Mail Removed)>,
Ross <(E-Mail Removed)> wrote:

> What are the best strategies for creating a Java application with a
> plugin architecture.
>
> My current plan is to have a directory of plugins, to read the files
> manually, use ClassLoader.defineClass to create the class file,
> Class.newInstance() to make one, and of course a number of interfaces
> that plugins can implement, one for each plugin type.
>
> Are there any better strategies that people would recommend? I don't
> want to add the plugin directory to the classpath, as that would make
> installation of the software more tricky than just putting a .jar
> file somewhere and double clicking on it.


IIRC, this fractal project has a similar plugin architecture that
modifies templates written in Java and compiles them _in_situ_:

<http://sourceforge.net/projects/benojt/>

Arachnophilia invokes fixed-signature methods by name, apparently using
introspection:

<http://vps.arachnoid.com/arachnophilia/Documentation/
JavaCustomClassInterface.html>

Here's a platform-specific example:

<http://home.roadrunner.com/~jbmatthews/java/macarach.html>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
 
Reply With Quote
 
Ross
Guest
Posts: n/a
 
      10-05-2009
On Oct 5, 7:10 pm, "John B. Matthews" <(E-Mail Removed)> wrote:
> IIRC, this fractal project has a similar plugin architecture that
> modifies templates written in Java and compiles them _in_situ_:
>
> <http://sourceforge.net/projects/benojt/>
>
> Arachnophilia invokes fixed-signature methods by name, apparently using
> introspection:
>
> <http://vps.arachnoid.com/arachnophilia/Documentation/
> JavaCustomClassInterface.html>
>
> Here's a platform-specific example:
>
> <http://home.roadrunner.com/~jbmatthews/java/macarach.html>


Those are both very interesting technological solutions. E.g
Arachnophilia allows objects to be treated as satisfying an interface,
even if it formally doesn't. I've done something similar in
writing a compatibility layer for Max/MSP Java objects that route
messages to matching methods. (Using Introspection).

But I'm not sure I need to be quite that sophisticated in my current
application. Either loading the classes as bytes as in my first
solution, or using a .jar file relative class paths and Class.forName
() are simpler, and suitable, solutions.
 
Reply With Quote
 
Dave Searles
Guest
Posts: n/a
 
      10-05-2009
markspace wrote:
> Ross wrote:
>> What are the best strategies for creating a Java application with a
>> plugin architecture.
>>
>> My current plan is to have a directory of plugins, to read the files
>> manually, use ClassLoader.defineClass to create the class file,
>> Class.newInstance() to make one, and of course a number of interfaces
>> that plugins can implement, one for each plugin type.
>>
>> Are there any better strategies that people would recommend? I don't
>> want to add the plugin directory to the classpath, as that would make
>> installation of the software more tricky than just putting a .jar file
>> somewhere and double clicking on it.

>
>
> If you are using a Jar file, it wouldn't look at the class path anyway.
> You have to set the Class-path property in the manifest file of the Jar
> file to change the class path of a Jar.
>
> If you add "." to the class path on the manifest, then the regular old
> class loader will look in the Jar's home directory for resources, and
> classes. If you add "plugin" (I don't think a / is required, although
> it might be), the class loader will also look in a directory of the same
> name in the home directory of the Jar file.
>
> You may have to fuss around a bit to get Jars loaded instead of loose
> classes, and to devise a good naming scheme that works for you and isn't
> too hard on your clients. I haven't actually implemented such a thing
> so I can't really offer any advice.


I'd dispense with the reflection and newInstance crap too. Instead, each
plugin would come as .class files and a .obj file. Plugin enumeration
consists of finding all the .obj files in ./plugins, then reading them
as serialized Java objects and casting to Plugin. The Plugin
class/interface defines methods that allow querying the plugin, and
appropriate other methods. For example a codec might have a code and a
decode method, and an added document type document factory methods to
produce document objects of some class or another. If a plugin is
installed incorrectly, either it doesn't show up (.obj file missing) or
deserializing the .obj doesn't work (some .class is missing or broken
and ObjectInputStream throws ClassNotFoundException or
InvalidClassException, or the .obj is broken and one gets
StreamCorruptedException or plain old IOException).

The plugins of course can have nice installers, or just come as zips to
be unzipped into the plugins directory.

The closest this comes to reflection is the use of serialization and a
cast. It makes for much nicer code that just does I/O and then has
factory/etc. objects in a list somewhere.
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      10-05-2009
On Mon, 5 Oct 2009, Ross wrote:

> What are the best strategies for creating a Java application with a
> plugin architecture.


The officially supported one.

One! You define an interface for your plugins.

Two! You package plugin implementations in JAR files, using the Service
Provider layout:

http://java.sun.com/javase/6/docs/te...ice%20Provider

Three! You put JARs on the classpath. Under java 6, the best way to do
this, IMHO, is with a wildcarded relative path in the JAR's Class-Path
attribute; something like:

Class-Path: plugins/*

That will add all JARs in the plugins directory adjacent to your app JAR
to the classpath.

On pre-6 javas, there are no wildcards, so the only way to add multiple
JARs is by explicitly listing them in the Class-Path, which is lame, or
putting them in the JRE's ext directory, which is lame, or by somehow
merging JARs at runtime, which is lame. Or some classloader trickery,
which is not lame, but is voodoo. You pays your money and you takes your
choice.

Four! You look the plugins up using java.util.ServiceLoader:

http://java.sun.com/javase/6/docs/ap...iceLoader.html

Unless you're on a pre-6 java, in which case you use the celebrated but
undocumented sun.misc.Service (which has been there since 1.3) - consult
javap, google, and your pineal gland for details.

Or the ServiceRegistry from ImageIO (which has been there since 1.4), even
though you're not doing image IO:

http://java.sun.com/javase/6/docs/ap...eRegistry.html

tom

--
Yulava? Niob Yam!
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      10-05-2009
Ross wrote:

> That's an interesting way of doing it. I think I'm going to try both
> and then choose the best solution. I've never set a classpath in a
> manifest file, I really should do. There's a number of jar related
> functions I've never gotten around to trying, e.g. storing images and
> other resources in jar files.



If you make a short test program like this

public class Main {

public static void main( String... args ) {

URL url = Main.class.getResource( "/test" );
System.out.println( url );
url = Main.class.getResource( "/testdir/test2" );
System.out.println( url );
}
}

You can play around with the Class-path property and make files on the
file system to see what it finds and where. Handy to test things out
quickly.

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      10-06-2009
Ross wrote:
> What are the best strategies for creating a Java application with a
> plugin architecture.
>
> My current plan is to have a directory of plugins, to read the files
> manually, use ClassLoader.defineClass to create the class file,
> Class.newInstance() to make one, and of course a number of interfaces
> that plugins can implement, one for each plugin type.
>
> Are there any better strategies that people would recommend? I don't
> want to add the plugin directory to the classpath, as that would make
> installation of the software more tricky than just putting a .jar file
> somewhere and double clicking on it.


If the application is for developers then: create an interface, let
all plugins implement that interface and load using Spring.

For end-users you will need some GUI stuff and then your code
can do everything necessary.

Arne



 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      10-06-2009
Thomas Pornin wrote:
> According to Ross <(E-Mail Removed)>:
>> What are the best strategies for creating a Java application with a
>> plugin architecture.

>
> The Eclipse IDE is written in Java and uses plugins quite heavily.
> The Eclipse developers have found it wise to use the OSGi framework
> for that. OSGi is a published specification for some services;
> several implementations exist. The one which Eclipse uses is called
> Equinox and is open-source. See: http://www.eclipse.org/equinox/
>
> It is quite plausible that OSGi does much more than what you need. The
> main non-trivial thing that OSGi does is that it handles live updates of
> code (i.e. upgrading a plugin without stopping the application). Not
> every application really needs that...
>
> (I have not used OSGi extensively myself; I am just reporting that
> Eclipse uses it and its developers appear to be happy with it.)


But it only works well with the GUI update/install feature.

Unpacking something in the plugin directory usually goes wrong.

Arne
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
MCSD - Solution Architectures Gerry O. MCSD 16 11-08-2003 02:31 PM
Re: unused wires and VHDL architectures Neil Zanella VHDL 1 10-27-2003 12:32 AM
unused wires and VHDL architectures Neil Zanella VHDL 3 10-26-2003 01:39 PM
Configuration of multiple architectures Panic VHDL 1 09-01-2003 12:25 PM
Very high bandwidth architectures Kooky45 Cisco 1 07-11-2003 02:34 AM



Advertisments