Java and Tomcat class loading mechanism

Load classes are the basis for running programs, and understanding the class loading mechanisms of Java and Tomcat has a positive effect on developing and debugging Web applications more effectively. This article briefly introduces the Java and Tomcat class loading mechanism, we hope to help you.

JDK/JRE File Structure
After installing the JDK, the typical directory hierarchy is as follows (JDK 1.6.0):

The main catalogs and jars are outlined below:

<java_home>\bin: The executable file for the development tool contained in the JDK, in general, the PATH environment variable should contain the directory.
<java_home>\lib: Files used by development tools, including (1) Tools.jar: The jar package contains non-core classes that support tool classes and utility classes in the JDK. It also contains (2) The design-time (designtime) archive used by Dt.jar:BeanInfo, which tells the IDE how to display the Java components and how to customize them for developers. It mainly contains the related classes of swing.
<java_home>\jre\lib: Contains core classes, property settings, resource files, and so on, used by the JAVA runtime environment. For example: (1) Rt.jar: Boot Class (runtime class that makes up the Java Platform Core API), (2) Charsets.jar: Character conversion class.
In a typical Web application environment, where the CLASSPATH environment variable is set, it is usually necessary to include the following entries:

• Set the path variable so that we can run Java applications anywhere in the system, such as Javac, Java, Javah, and so on, variable values: C:\jdk1.6.0\bin;

The classpath environment variable is when we need to refer to a class that someone else has written when developing a Java program, let the Java interpreter know where to look for the class. C:\jdk1.6.0\lib\tools.jar; C:\jdk1.6.0\lib\dt.jar.

• Set Java_home: A handy reference. C:\jdk1.6.0

Note: In a Web environment that uses Tomcat as the servlet/jsp container, Tomcat clears the original classpath content and re-defines it during startup. See below for details.

Java class loading mechanism
Java Launcher (Java) initializes the Java virtual machine. The virtual machines search for the load class in the following order:

1. Boot class: The class that makes up the Java platform, including Rt.jar and some other important jar files;
2. Extension classes: Classes that use the Java extension mechanism, which are bundled into jar files and placed in the extension directory, each jar file in the Jre/lib/ext extension directory is set as an extension and loaded with the Java extension schema;
3. User class: A developer-defined class and a third-party class that does not take advantage of the extensibility mechanism, where the location of these classes is specified by the user, typically by using the-classpath command-line option or by using the CLASSPATH environment variable.
In response, the JVM has used three different classloader since the J2SE 1.2 specification:

• Boot class (Bootstrap) loader (also known as the initial class loader);
• Extension class loader;
• System class loader.
These classloader are hierarchical, the system ClassLoader is at the bottom, and the boot ClassLoader is on the upper level, and the relationship between them is a parent-child relationship.

• Boot class loader: The boot ClassLoader is used by the JVM to load the Java classes that it needs to run. In fact, the boot ClassLoader is responsible for loading all of the core Java classes (such as java.lang.* and java.io.*). In general, various JVM vendors (including Sun) implement the bootstrap ClassLoader using native code.
• Extension class loader: Java 1.2 introduces a standard extension mechanism. The jar files can be placed in the standard extension directory, and the JVM will be able to find them automatically. The Extension class loader is responsible for loading all classes in one or more extended directories. In general, as long as the Java Runtime Environment (JRE) is installed, the extended directory is <jre>/lib/ext. The extension classloader may not be a standalone classloader, and some implementations might even allow the bootstrap ClassLoader to load classes from an extended directory.
• System ClassLoader: The system ClassLoader finds its own class in the jar file specified by the CLASSPATH environment variable, or passes the class through the-classpath command-line option, and, if not specified, uses the current directory by default. The system loader is also used to load the application's entry point class (that is, the class that contains the main () method), and the System class loader is used by default for any other classes that are not covered in the above two types of loaders.

• Delegation Model : The JVM knows which classloader to use by leveraging the delegation model. A later version of Java JDK 1.2, regardless of when the ClassLoader receives a request to load the class. Before a class loader attempts to load a requested class, it delegates the load request to its parent class loader until the class loader is booted. If the parent loader successfully loads the requested class, the class object that is the result is returned, and the original class loader attempts to mount the class only if the parent class loader fails to load the class.
Note: The class loader has more behavior:

Lazy Loading: The class loader above does not preload all classes in the search for that path. Instead, it loads the class as required. Such behavior is called lazy loading.
• Class caching: The standard Java SE Class loader can find classes as required, but once a class is loaded into the ClassLoader, it will remain loaded (cached) for a period of time. However, the JVM garbage collector can reclaim these class objects.
• Stand-alone namespaces: Each class loader is assigned a unique namespace.
Apache Tomcat 5.5 servlet/jsp class loading mechanism:
Like other server applications, Tomcat 5 installs a variety of Class loaders (that is, classes that implement the Java.lang.ClassLoader interface) to allow different parts of the container and Web applications running in the container to access libraries of different classes and resources available.

When Tomcat 5 was started, it created a class loader, which was organized into a parent-child relationship, with the parents loader on top of the subclass loader (the Tomcat 6.0 version of the ClassLoader hierarchy changed):

The loader is defined as follows:

Bootstrap: The loader contains the basic runtime classes provided by the JVM, plus the classes placed in the jar file of the System extensions directory (<JAVA_HOME\jre\lib\ext>). Note: Some JVMs implement the loader as more than one class loader, or it is completely invisible;
System: The system loader, which is typically initialized with the CLASSPATH environment variable. But the standard Tomcat 5 startup script (<catalina_home>/bin/catalina.sh or <CATALINA_HOME>\bin\catalina.bat> ) completely ignores the contents of the CLASSPATH environment variable and constructs the System class loader using the following libraries. As follows:

As you can see, the classpath used by Tomcat is not the directory we configured earlier.

<catalina_home>\bin\bootstrap.jar: Contains the main () method that initializes the Tomcat 5 server and the ClassLoader implementation it relies on;

<java_home>\lib\tools.jar: Contains the "javac" compiler used to convert the JSP page into a servlet class;
<catalina_home>\bin\commons-logging-api-x.y.z.jar: contains Commons logging API;
<catalina_home>\bin\commons-daemon.jar: contains commons daemon API;
Jmx.jar: Contains JMX 1.2 implementations.

Common: The ClassLoader contains additional classes that are visible to tomcat internal classes and Web applications. These include (1) jasper-compiler.jar:jsp 2.0 compiler (2) JSP-API.JAR:JSP 2.0 API (3) Servlet-api.jar:servlet 2.4 API, and so on.
Catalina: The loader initializes all classes and resources required to implement the Tomcat 5 itself;
shared: Classes and resources that are shared across all Web applications;
WEBAPPX: The class loader created for each Web app deployed on a single Tomcat 5 instance. Load classes and resources under/web-inf/classes and Web-inf/lib.
It is worth noting that the Web application ClassLoader behaves differently from the default Java 2 delegation model. When a request for a load class is processed by the WEBAPPX class loader, the ClassLoader will first look at the local library rather than delegating it before viewing it, but there are exceptions, classes that are part of the JRE base class cannot be overwritten, but for some classes, you can use J2SE 1.4 endorsed Standards Override mechanism. Finally, any jar package containing the Servlet API will be ignored by the ClassLoader. Tomcat 5 All other class loaders follow the common delegation pattern. See the Tomcat 5 reference documentation for specific details.

Java and Tomcat class loading mechanism