ModRun brings modularity to Java without the Jigsaw project. Modularity means the ability to package your applications and APIs as "modules" (JAR files) with extra meta data. The extra meta data tells what version the module (JAR file) is, and which dependencies (other modules in specific versions) your module uses. Having this meta data makes it easier to load your module and its dependencies into the JVM at runtime, as well as resolving dependency conflicts etc.
ModRun GitHub Repository
You can find the ModRun GitHub repository here:
ModRun Uses Maven Repositories
Instead of inventing a new module repository and meta data standard, ModRun uses the tried and tested Maven repository structure. ModRun can load modules directly from a Maven repository at runtime. This means that you can keep all your modules in a local Maven repository and load and run all modules directly from there.
Standardized Run Scripts
When all JAR files are loaded from a Maven repository, the scripts needed to run applications become much more standardized. You just tell what module that contains the main class to run, and ModRun resolves and loads all its dependencies too.
Building the Module Dependency Graph
When ModRun loads a module it builds a dependency graph for the module. The dependency graph contains all immediate and transitive dependencies for the module. This dependency graph can traversed and searched for classes. ModRun does this when loading classes. You can also traverse the dependency graph yourself.
One ClassLoader Per Module
ModRun assigns a separate ClassLoader to every module in the dependency graph. Remember, a module means an application or API in a specific version.
By loading the classes of a module with its own ClassLoader, ModRun can control what classes are visible to each module. A module can only see the classes from itself or from its dependencies (modules) and transitive dependencies. A module cannot see classes from modules "above" itself in the dependency graph.
By loading each module with its own ClassLoader, ModRun can load the same API in different versions into the JVM at the same time. The JVM will consider classes loaded from the two different versions of the API as different classes because they are loaded with different ClassLoader instances.
ModRun can also load the same module in the same version multiple times into the same JVM. Each instance of the module have the classes loaded from its dependency graph isolated from the other instances of the same module (at least it can - if you want to).
Loading the classes from each module with its own ClassLoader makes application multi tenancy easier. Application multi tenancy means having multiple separate applications run within the same JVM at the same time.
ModRun can load multiple applications into the same JVM at the same time, and have their classes be completely isolated from each other, so one application cannot access the classes of another application. ModRun thus provides a simple, secure model for application multi tenancy.
ModRun Java Example
Here is an example that creates a module from a Maven repository, loads a class from the module, creates an instance of the class and calls a method on the instance via reflection:
Repository repository = new Repository("test-repo"); Module modRunDepA = repository.createModule("com.nanosai", "ModRunDepA", "1.0.0"); String className1 = "com.nanosai.modrun.a.ComponentA"; Class theClass1 = modRunDepA.getClassFromThisModule(className1); Object theObject1 = theClass1.newInstance(); Method method1 = theClass1.getMethod("doIt"); String result1 = (String) method1.invoke(theObject1, new Object);