How do I let other developers integrate modules into my content generator?

Question

Background: I'm building a desktop app where user ability to develop mods is critical. At its bare bones it is a content generator where the content has many layers, and users can develop their own code to insert/generate content at any/every layer. All these user developed modules would be available to the user on the main gui in addition to the prepackaged modules, where they can select what modules are going to be used and configure generic as well as module specific options before beginning the generation process. Reasons for this design include integration of multiple peoples modules into one final result, as well as having parallelization, file I/O, and all the other rough challenges taken care of by the app so that the developer can solely worry about content generation.

This leads to the problem of the base approach to take when determining how to let them integrate their modules. Do I have them produce compiled libraries with certain interfaces and read them in at runtime? Since this is will likely be publicly on github, do I just let them extend base classes and compile the whole thing themselves? Is moddability best served by extending classes or by communication between objects?

As far as I can tell, I have to use Java, if that affects the design choices I take. The app has to be runnable on win/mac/linux and it would defeat the purpose if people who developed mods could only share them with people of their own OS. Although I could resort to scripting for the mods and simply compile the main app for all the different OSs, I'm not sure if that's the correct choice to take for this project. Perhaps that's part of this question as well.

Answer 1

As you're using Java (or really the JVM), this is pretty simple. You can load class files at run-time. This is almost certainly the most convenient thing for your end-users. Basically, to "install" a plugin, they'll copy class or jar files into a directory which your main application will search upon start-up (or whenever you like). You just use the ClassLoader to load the class files getting an Object and then cast it to the appropriate interface. You can consider variations on this including loading from the network.

All you need to do is declare interfaces that plugin developers will implement. You'll likely want to separate these into their own package so you can more easily distribute a Plugin Developer Kit or at least make it clearer what is and isn't part of the plugin API. You'll likely want an interface that all plugins must implement that provides meta-data. This allows you to query the plugin to know what kind of plugin it is (if you have different kinds), what versions of the main application it supports, and anything else that might be useful e.g. restrictions on OS. You do want to spend some time thinking about how to handle changing versions of your main application.

Answer 2

This leads to the problem of the base approach to take when determining how to let them integrate their modules. Do I have them produce compiled libraries with certain interfaces and read them in at runtime?

This is the approach that I have taken before. You define an ABI¹ that your users can build against and you also create a mechanism so that they can register their components with your application.

This also has the advantage of forcing you to be more rigorous in how you structure your own application and how you access the users' modules.

do I just let them extend base classes and compile the whole thing themselves?

IMHO this is the wrong thing to do. You now have no control over how the users interface to your application. So when you get complaints as to how their mods don't work, you will have no idea how to support them as to do so you will need to understand the internals of their code. In addition to even get to this point your users will have to have a deep understanding of your code.

The well defined ABI minimizes these issues.

---

^{1. ABI Application Binary Interface}