Making Life Easier for Java Devs: ModRun vs. Project Jigsaw

Written by Zaiku | Published 2016/12/15
Tech Story Tags: java | jvm | microservices | maven | tech

TLDRvia the TL;DR App

In a previous post we essentially introduced ModRun as a Java classloader capable of loading and running classes directly from Maven repositories and resolve dependencies at runtime. Today we`ll go a little bit further in pitching ModRun as a useful versatile tool helping Java developers release, (un)install, run, and upgrade Java apps, whilst also addressing some problems that the so — called `Project Jigsaw` did not solve yet (as far as we are aware).

If you are a Java developer we don`t need to remind you about the challenges and the hassle involved when installing and running Java applications. Yes there are several models out there trying to tackle this problem, but in our opinion none of them have really succeeded in making Java application installation and launch as easy as what we ought to do with ModRun. Especially if you keep multiple servers up-to-date with the latest versions of various services.

Before we proceed we`ll extend the definition of ModRun as a Java application installer/launcher/class loader that can load and run modules directly from a Maven repository. Another way to picture ModRun is as NPM or RPM just for Java apps. Now that we have extended the definition of ModRun, let us share with you how we plan to solve the following problems over coming weeks/months as the project matures:

  • 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 a developer needs 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 an application to a Maven repository makes the release very standardised and small. Developers only have to upload their 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 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 standardised.

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 a Java application’s JAR file is located in the local Maven repository structure, ModRun can load and run the application from there. All what is needed is to then give ModRun the path to the local Maven repository directory, and the groupId, artifactId, artifactVersion and main class to run, plus any additional command line arguments the application needs.

Running Java applications using ModRun makes the classPath very simple. Only ModRun’s JAR file is needed on the classpath. The application artifact and its dependencies are all 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. Good from a security point of view!:)

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).

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 standardised Java application/module repository structure, nor provides standardised installation and uninstallation procedures (as far as we know). ModRun provides all that! ModRun works with Java 8 of course, and we will make sure it will also work with Java 9.

Finally, in addition to the features described in the sections above, 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 GitHub Repository

ModRun is open source (Apache license 2.0) and can be found on GitHub here. Please feel free to check it out and star it if you like it and there are also some tutorials written by our Co — Founder and CTO at Nanosai, Jakob Jenkov.


Published by HackerNoon on 2016/12/15