Now, the project also introduces two JAR packages, A and B, as well as V0.1 and V0.2 of C.
Compared with V1, the log class of V2 adds the error method. For example, A and B depend on V1 and V2 of C, respectively. Therefore, there is no problem when compiling, but an error is reported at runtime because the loaded class does not match the expectation. Different JAR packages depend on different versions of some common JAR packages, such as log components. The situation above is common in the Java development process.
#JAVA REFLECTION LOAD CLASS CODE#
You only wrote your code for five minutes but spent the whole day arranging the packages.
After solving the problem, you start to be frustrated with the middleware because it has so many different versions of JAR packages. Then, you begin to find a solution and find a conflicting JAR package in hundreds of dependency packages. Everything is normal during compiling, but an error will be reported as soon as it runs:. The system has introduced a new middleware JAR package. If you write enough Java code, this will definitely happen. How can we avoid this situation? This article analyzes the causes of JAR package conflicts and the implementation principles of class isolation and shares two methods for implementing custom class loaders. During Java development, if different JAR packages depend on different versions of some common JAR packages, errors may occur during running because the loaded class is not the same as expected.
0 kommentar(er)
