Before JAVA 9, we will encounter some JAR-related problems: some are missing related dependencies, and some have multiple versions, which may lead to functional errors or even system crashes. For developers, it is easy to understand that each JAR has its own identity, and there are dependencies between components. But for JAVA, the JAR package is just a series of Class files and cannot describe the properties of the JAR package.
Errors that occur in JAR dependencies may be encountered in complex systems. Common such as:
1. NoClassDeffFoundError This occurs when the JVM executes dependent code. Finding missing dependencies is relatively easy, but analyzing the reasons for the absence can be relatively difficult. Generally, we use tools to generate dependency graphs, and then find out the reasons for the lack of relevant dependencies at runtime.
2. Shadowing This is only a different JAR package with the same name (package + class name). This situation is relatively rare. There was one encounter in the project. In the test environment, the JVM cannot find the Object method, but it cannot be reproduced in the local environment. Later, it was found that the same name exists in different JAR packages, and the order of loading the jar packages in the local and test environments is different, so it shows different effects.
3. Version conflicts are relatively common. We often introduce dependent JAR packages, which will introduce other dependencies. There may be multiple versions of the same JAR package. Generally speaking, the compilation tool will optimize this problem, warn us that there are multiple versions, and choose the latest version to use.
4. If the weak encapsulation of a module depends on a JAR package that crosses the boundary of the package, is it defined as public? This may lead to the fact that although some of our functions are defined as public, they are indeed used inside the module and should not be called for other JAR packages, but this problem cannot be fundamentally solved technically before the appearance of JAVA9.
5. Startup performance Many applications, such as using spring, consume a lot of time during startup. Although the JVM class is lazy load, when a class is needed, it needs to know which JAR package the class is in. Therefore, it is generally necessary to scan the JAR package at startup to ensure that the corresponding class path is known.
6. JRE tailoring If your application does not need Swing, SQL, XML, can you tailor these codes? JAVA 8 defines a subset of the three modules of the JRE, but these are fixed and cannot be dynamically adjusted, and cannot meet the need for partial tailoring of the JRE.
In the following articles, we will describe how JAVA 9 solves these problems. Most importantly, JAVA 9 will affect us in terms of design concepts, making everyone pay more attention to the module diagram and the dependency management between modules.