Class loading Framework control class loading in Java

By building a class loading component container framework that can isolate Java class loads into a specified jar file, you can ensure that runtime loads the component version you expect.

Java's class loading framework is powerful and flexible. It allows applications to access class libraries without having to link to static "include" files. Instead, it is able to load files containing library classes and resources from the specified location, such as directories and network locations defined by the CLASSPATH environment variable. The system dynamically resolves run-time references to classes and resources, simplifying updates and release releases. However, each library has its own set of dependencies-and it is up to developers and publishers to ensure that their applications properly refer to the correct version. Unfortunately, the combination of the default class loading system and specific dependencies can and does lead to errors, system crashes, and even worse situations.

In this article, I'll recommend you a container framework that implements class loading to solve these problems.

First, Java Classpath

java specifies the path that the runtime uses to find classes and other resources based on the environment attribute/variable CLASSPATH. You can define the Classpath property by setting the CLASSPATH environment variable or by using the Java command-line option--classpath.

Typically, a Java runtime finds and loads classes in the following order:

1. Classes in the Bootstrap class list-These are classes that embody the Java platform, such as those in Rt.jar.

2. Classes that appear in the list of extended classes-these classes use an extension mechanism framework to extend the Java platform, using files (. jar,.zip, and so on) in the/lib/ext directory of the runtime environment. )。

3. User Classes-These classes do not use the-classpath command-line option or the extension mechanism schema identified by the CLASSPATH environment variable.

Ii. Archives and Classpath

A file. A jar or a. zip file can include a manifest file-they contain portals that can be used to provide file information, set file properties, and so on. The manifest file can also be extended classpath by including a portal named Class-path (which contains a list of files and directories). JDK 1.3 introduces the Class-path manifest portal for specifying optional jar files and directories that can be loaded as needed. Here is an example of a Class-path entry:

Class-path:mystuff/utils.jar

Mystuff/logging.jar mylib/

Java provides an extensible model for specifying the location and file list of the loading classes. However, this raises a number of issues, such as the possibility that a different version of the library might exist in Classpath-this is beyond the expected results of an execution class.

Third, classpath version conflict

In Java, the Run-time identity of a class is defined by its fully qualified name (the package name before the class name, sometimes as FQN), all of which are added to the ID of the loading class's associated loader. Since then, each instance of a class loaded by multiple ClassLoader will be treated as a separate entity for the Java runtime. This means that the runtime can load multiple versions of the same class at any time. This is a very powerful and fairly flexible feature; however, some side effects may be confusing if a developer does not use it carefully.

You can assume that you are developing an enterprise application that uses similar semantics to access data from a variety of sources, such as a file system and a database. Many of these types of systems expose a data access layer-data Access Objects (DAO) that are abstracted like data sources. Now, imagine that you are loading a new version of a database DAO, using a slightly different API to meet the new features of a DAO client-but you still need the old DAO to be suitable for other clients that have not yet been prepared for this new API. In a typical run-time environment, this new DAO will simply replace the old version and all new instances will be created from the previous version. However, if an update occurs without stopping the runtime environment, then any instance of the old DAO that already exists will reside in memory with any instance of the new DAO-When these new instances are created. This is already puzzling. Worse still, a DAO customer expects to create an instance of an older DAO, but actually gets a new version of the changed API. As you can see, this may bring some interesting challenges.

To ensure stability and security, the calling code must be able to indicate the correct version of the class that it wants to use. To do this, you can create a class loader, a component container model, and use some simple class loading techniques.