​In our previous article of JVM internals series, we learned about what is JVM, basic architecture of JVM and briefly understood its components. In this article we will discuss in detail about Class Loader SubSystem component of JVM architecture .

Class Loader SubSystem

Java’s dynamic class loading functionality is handled by the Class Loader SubSystem. It loads, links and initializes the class when it refers to a class for the first time.
Class Loader SubSystem is responsible for following 3 activities

1. Loading 
2. Linking
3. Initialization

Loading

Loading means reading class files from hard disk and store corresponding binary data in method area. For each class file JVM will store corresponding information in method area, such as

1. Fully qualified name of class 
2. Fully qualified name of immediate parent class
3. Methods info
4. Variable info
5. Constructor info
6. Modifiers info
7. Constant pool info
8. whether .class file represents class or Interface or enum

After  loading .class file immediately jvm creates an object for that loaded class on the Heap memory of type java.lang.Class.

How many Class class object will be created in JVM?  (Important Interview Question)

For every loaded type, only one class Object will be created, even though we are using class multiple times in our program.  

Class class object can be used by programmer to get class level information like method info or variables info, constructor info etc.

Linking  

Linking consists of three activities

    1. verify (verification)
    2. prepare (preparation)
    3. resolve (resolution)

Linking a class or interface involves verifying and preparing

• that class or interface,
• its direct superclass,
• its direct super interfaces, and
• its element type (if it is an array type), if necessary.

Resolution of symbolic references in the class or interface is an optional part of linking.

Note: As linking involves the allocation of new data structures, it may fail with an OutOfMemoryError.

     1. Verification

Following points are checked in Verification process.    

• It is a process of ensuring that Binary representation of a class is a structurally correct or not.
• JVM will check whether the .class file is generated by valid compiler or not.
• .class file is properly formatted or not.
• Internally Bytecode verifier is responsible for this activity.
• Bytecode verifier is a part of Class Loader SubSystem.
• If the binary representation of a class or interface does not satisfy the static or structural constraints then a VerifyError is thrown. An error thrown is an instance of LinkageError (or its sub class).

Why Java is Secured Language?  (Important Interview Question)

Bytecode verifier is one of the feature which makes java a secured language. If attackers changes the class file manually to create some kind of virus, Bytecode verifier will detect that class file as it is not generated by valid compiler.  Verfication fails, we will get runtime exception saying java.lang.VerifyError 

     2. Preparation

In this phase, JVM will allocate memory for class level or interface level static variables and assign default values.

In initialization phase, original values will be assigned to the static variables and in preparation, only default values will be assigned.

    3. Resolution

Resolution is the process of dynamically determining concrete values from symbolic references in the run-time constant pool. In simple words, it is the process of replacing symbolic names in our program with original memory references from method area.

Let us understand this by an example.

public class Testing {

	public static void main(String[] arg) {
		String s = new String("Pumpkin");
		Student s1 = new Student();
	}
}

For the above class, class loader loads 

1.  Testing.class
2.  Object.class – parent class
3.  String.class
4.  Student.class

• The names of this classes are stored in constant pool of Testing class.
• In resolution phase, these names are replaced with original memory level references from method area.
• All symbolic references, that were now loaded into the method area in form of the runtime constant pool, are resolved to actual types loaded by this JVM.

• If a symbolic reference can be resolved but results in a conflict of definitions, a IncompatibleClassChangeError is thrown. If method lookup fails, method resolution throws a NoSuchMethodError. If method lookup succeeds and the method is abstract, but Class is not abstract, method resolution throws an AbstractMethodError and so on.  All of the above errors are subclass of java.lang.LinkageError class.

Initialization

In 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 runtime exception saying java.lang.LinkageError or its subclass java.lang.VerifyError.

In-depth explanation of Class Loader SubSystem is beyond the scope of this article. Still we have tried to make it as simple as we can. You may refer the following links for further jvm understanding. We will be including more articles in JVM Internal Series.

1. IBM Technology for Java Virtual Machine in IBM i5/OS by Aleksandr Nartovich, Adam Smye-Rumsby, Paul Stimets, George Weaver
2. https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.3
3. TheJava® Virtual Machine Specification JavaSE 7 Edition