ModRun: Modularity for Java — Without Jigsaw
ModRun: Modularity for Java — Without Jigsaw
The Nanosai team is working on a new tool to help release, (un)install, run, and upgrade Java apps, all while also covering some aspects that Jigsaw will miss.
Join the DZone community and get the full member experience.Join For Free
Bring content to any platform with the open-source BloomReach CMS. Try for free.
Installing and running Java applications has been challenging in the past. There are several models, but none that have really made Java application installation and launching easy. Especially if you keep multiple servers up-to-date with the latest versions of various services.
To meet that challenge, we (Nanosai) are now developing ModRun. ModRun is short for Module Runner. In ModRun context, a module is a Maven artifact in a specific version (a JAR file). In this short article, I will give you an overview of what ModRun is, and what it can do for you.
ModRun is a Java application installer/launcher/class loader that can load and run modules directly from a Maven repository. In that way, ModRun is akin to NPM or RPM — just for Java apps.
ModRun solves the following problems:
- Release of Java applications.
- Installation of Java applications from remote repositories.
- Running of Java applications stored in a local Maven repository.
- Upgrading Java applications.
- Uninstalling Java applications.
Release of Java Applications
Since ModRun can download applications directly from Maven repositories, all you need to do to release a Java application is to publish its Maven artifact (JAR file) to a Maven repository. ModRun can download it from there, resolve its dependencies and download them, too.
Publishing your application to a Maven repository makes release very standardized and small. You only have to upload your application's JAR file, assuming that all dependencies are already stored in the Maven repository.
Installation of Java Applications
As mentioned already, ModRun will be able to download your application's JAR files directly from a Maven repository. ModRun stores the JAR files locally in what corresponds to a local Maven repository (the same directory structure and location of JAR and POM files). This makes installation of applications and their dependencies pretty standardized.
Keeping application JAR files and their dependencies in a local Maven repository structure makes it easy to have multiple versions of an application installed at the same time.
Running Java Applications
Once your Java application's JAR file is located in the local Maven repository structure, ModRun can load and run your application from there. All you need to give ModRun is the path to the local Maven repository directory, and the groupId, artifactId, artifactVersion and main class to run, plus any additional command line arguments your application needs.
Running Java applications using ModRun makes the classPath wonderfully simple. Only ModRun's JAR file is needed on the classpath. The application artifact and its dependencies are resolved at runtime, and loaded using ModRun's special ClassLoader structure.
ModRun's special ClassLoader structure can resolve and load the dependencies of a Maven artifact at runtime. The ClassLoader structure is capable of isolating the dependencies of a module (artifact) from the dependencies of other artifacts. That means that it is possible to load different versions of the same artifact into memory, even within the same application (provided certain conditions are met). ModRun can also load the same application into the same JVM multiple times (or different applications), and keep them completely isolated from each other.
Upgrading Java Applications
Upgrading a Java application with ModRun is no more difficult than installing it in the first place. The new version is downloaded from a remote Maven repository and installed in the local, along with any new dependencies.
Uninstalling Java Applications and Dependencies
When ModRun installs artifacts in the local Maven repository structure, it keeps track of what artifacts are applications and what are just dependencies. This way, ModRun can easily uninstall an application — or a specific version of an application.
After uninstalling an application ModRun can traverse the whole local Maven repository structure and find out what dependencies are no longer referenced by any applications. These dependencies can then be deleted too (they can always be downloaded easily again, if needed in the future).
How Much Is Working Right Now?
What is described above are the features we aim at for ModRun in the long run. ModRun is currently capable of running Java applications from a local Maven repository structure. You will have to place your application JAR file there in the correct structure, along with its dependencies, for ModRun to be able to run it.
The internal ClassLoader structure has been proof-of-concept tested, but it needs a few adjustment and control levers.
We are working on the remote download features, and already have some of the working by now, but there is still more work to do in this area. For instance, applications should probably get a data directory too, and not just be a JAR file in a Maven repository.
The uninstall features are also a bit into the future, but we don't suspect those will be the hardest to implement.
In addition to the above features, we have many other ideas for ModRun. For instance, features for keeping large grids of servers up-to-date with the same Java applications (e.g. microservices), or upgrade the servers in groups (alpha servers, beta servers and the rest).
ModRun vs. Jigsaw
ModRun solves some of the same problems as project Jigsaw in Java 9. However, Jigsaw does not solve artifact versioning, nor provide a standardized Java application/module repository structure, nor provides standardized installation and uninstallation procedures (as far as we know). ModRun provides all that.
ModRun works with Java 8, and we will make sure it will also work with Java 9.
ModRun GitHub Repository
ModRun is open source (Apache license 2.0) and can be found on GitHub here.
Opinions expressed by DZone contributors are their own.