The Jigsaw project solves the Java JAR hell problem.

The Jigsaw project solves the Java JAR hell problem.

Nicola Parlog is a enthusiastic software engineer who is an avid supporter of copyright and open-source software. He has made significant contributions to projects such as AssertJ, ControlsFX, FindBugs, and Property Alliance. Recently, Parlog wrote an article on the Jigsaw project, talking about some shortcomings and improvements of the Jigsaw project. The Jigsaw project has ambitious goals. One of its goals is to completely eliminate the JAR hell issue in the highly error-prone and problematic class path mechanism. However, although other goals of the project will be achieved in the near future, it does not seem so easy to solve the JAR hell problem.

To better understand what we will discuss next, let's first take a look at the JAR hell problem. Next we will introduce what aspects of the Jigsaw project will solve the problem, and why does the problem solved by Jigsaw not affect the entire problem domain in essence. Finally, let's take a look at the official positions on this topic and give a proposal on how to prevent the appearance of module hell.

JAR hell Problems

JAR hell has the following loop problems:

Unclear expressions and pass-through dependency masking version conflicts complex class loading

According to the various functions and features brought to us by building tools and component systems (called containers by JDK developers), we can think that the problem of unclear expressions and transmission dependency has been solved to a large extent, the masking problem is at least mitigated, and complex class loading is no longer a common problem. In this way, version conflicts become the most serious issue in JAR hell, which affects the daily update decisions of many projects.

What changes will Jigsaw bring about?

I have previously written a special article on what new features the Jigsaw project will bring to Java 9, but here I will explain it from different perspectives. First, it will be affected by the current early access to the build version. Second, we will only introduce it from the perspective of JAR/module hell.

The core concept of Jigsaw for Java is Modularization. In short, a module is like a JAR with some additional information and features. The information includes the name of the module and the name of other modules that the module depends on.

Dependency

When the compiler and JVM are processing modules, they will parse the information. During compilation or startup, they will parse all dependencies through module path pass-through. In general, this is similar to classless path scanning, but now we are looking for the entire module rather than a single class. For JVM, this is done during the startup rather than runtime. If all dependencies cannot be found in the module path, the module's transfer dependency fails to be parsed. This clearly solves the problem of unclear expressions and endless transmission dependencies. I think this is a great practice. The Java language now officially knows the dependency information. All the tools (compiler and JVM) can understand this and use it normally! However, I don't think this will have a very positive impact on the daily work of developers, because many existing infrastructures have already solved this problem, such as building tools.

Masking

Jigsaw eliminates masking. The module system can ensure that each dependency is implemented by another module. Each module reads at most one module, and modules that define packages of the same name do not interfere with each other. More accurately, the module system terminates and reports an error in case of ambiguity. For example, the two modules export the same package to the same module.

Version conflict

We believe that version conflicts of third-party libraries are the most difficult problem to solve in JAR hell. The most direct solution is that a module system can load different versions of the same module. This requires that these versions do not interact with each other. The problem is: in a single configuration, there is no need to support multiple versions of a module. In fact, the current build neither creates nor understands the module version information. Some workarounds have been used. The ugliest and most feasible way is to rename conflicting components, so that they are no longer two different versions of the same module, but two completely different modules. However, this practice proved to be unfeasible. Obviously, it is ensured that "modules defining packages with the same name do not interfere with each other" is implemented by rejecting any startup configuration when the two modules export the same package. Even if no module reads them!

Complex class loading

It is very difficult to interact between modules and classloaders and to change the complexity of classloading. In fact, the module system imposes no restrictions on the relationship between modules and class loaders. The class loader can load types from one or more modules, as long as there is no mutual interference between modules, and each module type can only be loaded by one loader. Therefore, the class loader has a one-to-multiple relationship with the module.

Module hell?

Since the dependency and masking problem has been solved and the class loading problem has been improved, why should I discuss module hell? Is it because of version conflict? That's right! If Jigsaw wants to solve the JAR hell problem, it needs to pay special attention to the version conflict issue. Otherwise, many projects do not have any improvement. They still have to deal with version conflicts and get stuck in the nightmare of custom class loaders.

Proposal

My proposal is to allow developers and build tools to transmit some additional information that can solve some ambiguous problems. Two common ways to pass this information are the command line and configuration file. If you use the command line parameter, you must enter the parameter once each time you start. This approach may become boring based on the amount of information and the size of the project. You can create a configuration file using the build tool, and then specify the configuration file through the command line. This looks like a good solution. At present, the initial module and all the transmission dependencies are parsed through a single configuration, which forms a separate layer. However, we can load multiple versions of the same module into different layers at runtime, which is exactly what the component system is going to do. In general, my suggestion is to explicitly specify the configuration through multiple layers.