• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Dynamically finding classes that implement an interface

 
Ranch Hand
Posts: 299
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 299
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Brian Pipa
Ranch Hand
Posts: 299
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 299
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic