In Java Virtual machine it is necessary to have a class loader subsystem. .class files are read and loaded with this class loader subsystem and it saves the bytecode in the JVM method area
- Loading
- Linking
- Initialization
Loading
As the Class loader subsystem reads class files which are stored in the hard disk, it performs the loading functionality.
- Fully qualified name of class
- Fully qualified name of immediate parent class
- Methods info
- Variable info
- Constructor info
- Modifiers info
- Constant pool info
- whether .class file represents class or Interface or enum
Storing these corresponding information in the method area can be defined as loading. In general it means storing corresponding binary data and reading the .class files.
When the class files are loaded the JVM creates an object for the class which is loaded, on the Heap Memory of type java.lang.Class.
When a programmer needs to get the method info or variable info or Constructor info, these created class objects are used.
Linking
Linking consists of three activities
- verify (verification)
2. prepare (preparation)
3. resolve (resolution)
These three main performances are consisted in linking
- that class or interface,
- its direct superclass,
- its direct super interfaces, and
- its element type (if it is an array type), if necessary.
preparing and verifying the above is the process of linking. There is an optional area in linking as resolution of symbolic references in the class or interface.
As linking involves the allocation of new data structures, it may fail with an OutOfMemoryError.
1. Verify (Verification)
Verification is a process that verifies the validity of the generated class file. Whether it is compiled by a valid compiler or not, whether the .class file is properly formatted or not. It ensures the binary reputation of the class is structurally well generated. Bytecode verifier is the internal build verifier which is responsible for the verification process. This is built within the class loader subsystem
runtime exception java.lang.VerifyError occurs in instances where the bytecode verifier fails. An error thrown is an instance of LinkageError (or its subclass).
In making Java a secured language, Bytecode verifier plays an ultimate role. When a class file is changed or updated manually by any third party, the Bytecode verifier finds that the class file is not created or generated through a valid compiler. When the process of Verification fails, we will get runtime exception saying java.lang.VerifyError
2. Prepare (Preparation)
In this phase, allocation of the memory for class level or interface level static variables and assign default values by JVM will happen.
Only default values will be assigned to static variables in this process as the original values will be assigned in the initialization process.
3. Resolve (Resolution)
It is the process of replication of symbolic names in our program with the original memory reference from the method area.
For the above class, class loader load Testing.class, String.class,Student.class, Object.class. The name of these classes are stored in constone pool Testing class in resolution face this name are replation with the original memory level reference of method area.
There are few errors which can occur in subclass of java.lang.LinkageError.
IncompatibleClassChangeError is thrown when a symbolic reference is resolved but results in a conflict of definitions. NoSuchMethodError. Is thrown by method resolution when the method lookup fails. When the method lookup succeeds and the method is abstract, but Class is not abstract, then AbstractMethodError is thrown by the method resolution.
Initialization
In the Initialization phase, all static variables are assigned with original values and static blocks will be executed from parent to child and from top to bottom.
While loading, linking and initialization, if any error occurs, we will get a runtime exception saying java.lang.LinkageError or its subclass java.lang.VerifyError.
Type Of Class Loader
Class loader subsystem contain following 3 type of class loaders
- Bootstrap Class Loader | Primordial Class Loader
- Extension Class Loader
- Application Class Loader | System Class loader
1. Bootstrap Class Loader — Primordial Class Loader
Bootstrap class loader is responsible to load core JAVA API classes that is class presenting rt.jar
jdk >> jre >> lib >> rt.jar — This location is called bootstrap class path.
That is bootstrap loader is a responsible loader the class is from bootstrap class path.
Bootstrap class loader, is by default available with every JVM, it is implemented in native languages like C or C++ under not implemented in JAVA.
2. Extension Class Loader
Extension Class loader is the child class bootstrap class loader. Extension class responsible to load class from extension class path.
jdk >> jre >> lib >> ext >> *.jar
extension class loader is implemented in java. Under the responsible .class file is sun.misc.Louncher$ExtClassLoader.class
3. Application Class Loader | System Class Loader
Application class loader is the child class of Extension class loader. This class loader is responsible for loading class loaders from the application class path. It internally uses Environment variable class path.
Application class loader is implemented in java under the responding .class file name is sun.misc.Louncher$AppClaasLoader.class.
How to Work Class Loader
Class loader follows delegation Hierarchy principle. Whenever a JVM comes to a particular class 1st it will check whether the responding .class file is already loaded or not, if it is already loaded in the method area the JVM will consider that loaded class.
If it does not load the JVM request class loader subsystem to the lord particular class, then class loader subsystem handover requests to Application class loader.
Application class loader delegates the request to Extension class loader which intron delegation request to bootstrap class loader.
Then the bootstrap class loader will search in the bootstrap class path. If it is available the responding .class will be loaded by bootstrap class loader. If it is not available then the bootstrap class loader delegates the request to the extension class loader.
extension class loader will search in extension class path. if it is available then it will load otherwise extension class loader delegated request to application class loader.
Application class loader will search in application class path. If it is available then it will be loaded otherwise it will get a runtime Exception NoClassDefFountException or ClassNotFoundException.
Reference
- JVM Architecture: JVM Class loader and Runtime Data Areas : https://www.javacodegeeks.com/2018/04/jvm-architecture-jvm-class-loader-and-runtime-data-areas.html
- Class Loader in Java : https://www.geeksforgeeks.org/classloader-in-java/
- The JVM Architecture Explained : https://dzone.com/articles/jvm-architecture-explained
- Loading, Linking, and Initializing : https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html
- Class Loader in Java : https://www.javatpoint.com/classloader-in-java
