File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Dynamically finding classes that implement an interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Dynamically finding classes that implement an interface" Watch "Dynamically finding classes that implement an interface" New topic
Author

Dynamically finding classes that implement an interface

Brian Pipa
Ranch Hand

Joined: Sep 29, 2003
Posts: 299
Hi all,
I am in the process of designing a plugin architecture for one of my Java apps. Suppose I create an interface called com.filenabber.maccc.Output - is there a way to dynamically find all classes on the classpath that implement that interface? I'd like to put a plugins directory on the classpath then dynamically load classes or maybe jars from that dir and find out which classes implement my interface so I can then do things with these "plugins" in my program.
Any ideas?
Thanks,
Brian


My Java Freeware:<br />MACCC - <a href="http://maccc.pipasoft.com" target="_blank" rel="nofollow">http://maccc.pipasoft.com</a><br />Nator - <a href="http://nator.pipasoft.com" target="_blank" rel="nofollow">http://nator.pipasoft.com</a>
David Weitzman
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
You can, in theory, run through all .jar files and directories on the classpath and examine the classfiles to see if an interface is implemented. This may be slow depending on the size of path and you would want to read the classfiles directly rather than calling Class.forName() because loading everything on the classpath into memory is a bad idea. At the very least you would probably want to identify plugin classes by some naming convention or require them to be in a certain package. Also you run into problems with plugins that may exist in the classpath but that you don't want to load.
Simply requiring the names of plugins to be specified in a text file somewhere tends to be a pretty reliable way of managing them.
Brian Pipa
Ranch Hand

Joined: Sep 29, 2003
Posts: 299
I thought about the text file solution, but I don't want people to have to edit a config file to enable a plugin. I want them to download a .class/.jar, put it in the right place, and it just works.
I guess I should look at how other Java apps do plugins. I know JEdit and Eclipse do plugins - anyone know of others?
I did a quick lookover of JEdit and it has a plugins directory and for each plugin, there is a directory under plugins. I think I could do something like this. I can add each dir under plugins to the classpath and in each dir I can require a .properties or .xml file that defines the plugin classname. That should work nicely. Thanks for the help/brainstorming.
Brian
[ January 05, 2004: Message edited by: Brian Pipa ]
Azriel Abramovich
Ranch Hand

Joined: Dec 10, 2003
Posts: 38
I think that you have a good solution. Separating different plugins into different directories is even better that enforcing some naming convention, this way a single plugin can go for different elements (many interfaces).
Of course, the best idea is to just have a directory where all plugins fall into and thus make the 'users' life easier, but considering performance vs. ease of use I think you've got it.
I think eclipse have some of the data regarding the plugin in an xml file, so in essense there is no magical solution
One other solution is to enable a registration mechanism (through API) for plugins, where when a user adds a plugin he/she registers the plugin. This is the most 'efficient' for you because it takes the load of your shoulders and puts it on the 'users'. But then you don;t have a mechanism like you wanted
Good luck!


Don't be shy, be quiet!
Brian Pipa
Ranch Hand

Joined: Sep 29, 2003
Posts: 299
Originally posted by Azriel Abramovich:
Of course, the best idea is to just have a directory where all plugins fall into and thus make the 'users' life easier, but considering performance vs. ease of use I think you've got it.

Yeah - I was thinking about that. I could just have the plugins be packaged in a .jar and you put the .jar into the plugins directory. At startup, I put all of the .jars on the classpath then open each .jar and look for the plugin descriptor that tells me some info (name of plugin, plugin class, etc.). This would make it easy on the user/downloader of the plugin, and shouldn't be too hard to code. I haven't ever really played around with classloaders to dynamically read the plugins dir and put the .jars on the classpath, but it's something new to learn
I'll definitely write the plugin code to be generic enough that I (or others) can use it in other apps. Assuming I can get it to work, I'll probably release as free, open-source code.
Originally posted by Azriel Abramovich:
One other solution is to enable a registration mechanism (through API) for plugins, where when a user adds a plugin he/she registers the plugin. This is the most 'efficient' for you because it takes the load of your shoulders and puts it on the 'users'. But then you don;t have a mechanism like you wanted

I don't see a huge amount of plugins being developed (maybe 5 at the most) so I don't think it's a big deal for me to host them on my site and keep track of them. So, I think a registration mechanism of plugins might be overkill.
Brian
[ January 06, 2004: Message edited by: Brian Pipa ]
Brian Pipa
Ranch Hand

Joined: Sep 29, 2003
Posts: 299
I found a thread about this very thing here:
http://makeashorterlink.com/?M6E6429F6
Ok, no more posting to this thread. I swear. Somebody close it
Brian
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Dynamically finding classes that implement an interface