I'm working on a Java project and I would like to add a plug-in system. More precisely, I would like to let the user design his own module, pack it into a jar, leave it in a "plugins/" subfolder of my application and be done with it. I've managed to get a child classloader to instantiate objects of classes located in external jars, but now I'm facing a design dilemma:

Say Joe makes a plug-in and he packs it in joeplugin.jar. I would really like Joe to have a class named "instantiation.Factory" and I would also like everyone to have this class with this exact location and name. (This factory class obviously implements a interface that I provide and through it I get what I want from the plug-in.) If Joe wouldn't be restricted in this way I would have to look into his entire jar for some class that implements my factory interface and I don't want to imagine how complicated things get.

So my question is: should I enforce a strict naming convention for this single class? I have no idea how plug-in systems work.

2 Answers 2


Look at the service locator in java. One of the main classes is java.util.ServiceLoader. It basically searches for a file named as an interface and loads the class named in this file. This is the standard way to load classes dynamically as plug-in.


Presumably you define "PluginInterface" and require JoePlugin implements PluginInterface. Beyond that, there's no limit to how much stuff you pack into PlugIninterface, except that if you make it too complicated you'll inhibit plugin builders.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.