Core Java With OCJP/SCJP:JVM Architecture Part- 2|| Linking ||verfi|| prepare||resolve

Understanding JVM Architecture: Class Loading and Linking

Class Loading Subsystem Overview

• The class loading subsystem in JVM is responsible for three main activities: loading, linking, and initialization.

• During the loading phase, class data is read and stored in the method area. An object of type 'class' is created in the heap area to access class-level information.

Linking Phase Activities

Verification, Preparation, and Resolution

• The linking phase consists of three activities: verification, preparation, and resolution.

• Verification ensures that the binary representation of a class file is structurally correct. It checks if the class file was generated by a valid compiler.

Importance of Verification

• Java is considered secure compared to other languages like C or C++ because it includes a bytecode verifier that prevents harmful code execution.

• The bytecode verifier checks if the class file adheres to structural correctness and whether it was produced by a legitimate compiler.

Role of Bytecode Verifier

Security Mechanism

• If a class file does not meet these criteria (e.g., potentially harmful code), the bytecode verifier raises an error (java.lang.VerifyError).

• This mechanism allows Java classes to run on any system without security warnings typically associated with other programming languages.

Detailed Functionality

• The verification process involves checking if the binary representation of a class file is properly formatted and generated by a valid compiler.

• The bytecode verifier plays an essential role in ensuring that no malicious code can spread through Java applications.

Verification and Preparation in Java Class Loading

Verification Process

• The white code verifier is a component of the class loader subsystem, responsible for ensuring that the bytecode adheres to Java's safety and security standards.

• If verification fails, a runtime exception occurs, specifically a java.lang.VerifyError, indicating issues with the bytecode's validity.

• Verification is crucial as it contributes significantly to Java's security model by preventing invalid or malicious code from executing.

Preparation Phase

• During the preparation phase, memory is allocated for static variables at class loading time, and default values are assigned to these variables.

• The preparation phase involves assigning default values rather than original values; original values will be assigned later during the initialization phase.

• JVM allocates memory for class-level static variables and assigns them default values during this stage, which is essential for proper variable management.

Initialization Phase

• In the initialization phase, original values are assigned to static variables after their default initialization has occurred.

• This distinction between default value assignment (in preparation) and original value assignment (in initialization) is critical for understanding variable lifecycle in Java.

Resolution Phase

• The resolution process addresses compile-time errors related to symbols such as methods or classes that cannot be found, often resulting in messages like "cannot find symbol."

• During resolution, symbolic references in the code are replaced with actual memory references when executing the program. This ensures that method calls point to their correct implementations.

• All symbolic references are stored in the method area of memory, where they get replaced with corresponding memory-level references before execution begins.

Example of Symbolic Reference Replacement

• An example illustrates how symbolic references (like method names or class names used in code) are resolved into actual memory addresses during execution.

• A simple class structure demonstrates this concept by showing how various symbols within a program relate to their respective implementations through resolution.

Understanding Symbolic References and Memory Management

Symbolic References in Programming

• The discussion begins with the concept of symbolic references, highlighting that terms like "test," "main," "a," and "string" are symbols that represent memory-level references.

• Class-level symbols such as "test," "string," and "student" are identified, emphasizing their role in referring to original memory locations during program execution.

Resolution Phase Explained

• The resolution phase is defined as the process where all symbolic names in a program are replaced with their corresponding original memory-level references.

• This phase involves replacing symbolic names with actual memory addresses from the method area, ensuring proper reference during execution.

Example of Class Loading

• An example is provided involving a class named test, which includes string declarations and instantiation of a student object.

• A question arises regarding how many class files will be loaded by the JVM for this program, identifying four key classes: test.class, object.class, string.class, and student.class.

Constant Pool Insights

• All symbols used in the program are stored in the constant pool of the test class, indicating that every symbolic reference corresponds to a constant within this pool.

• It is noted that each symbol will eventually be replaced with its respective memory-level reference from the method area.

Linking Phases Overview

• The linking process consists of three phases: verification (ensuring valid compilation), preparation (allocating memory for static variables), and resolution (replacing symbolic references).

• During initialization, original values for static variables are assigned, and static blocks are executed—this differs from preparation where no static block execution occurs.

Class Loader Subsystem Overview

Initialization Process

• The initialization phase involves assigning original values to all static variables and executing static blocks in a specific order.

• Execution of static blocks occurs from parent to child and from top to bottom, emphasizing the hierarchical nature of class loading.

Class Loader Activities

• The class loader subsystem is responsible for three main activities: loading, linking, and initialization.

• Linking consists of three phases: verification, preparation (allocating memory for static variables), and resolution.

Detailed Breakdown of Activities

• After loading, the next steps are verification followed by preparation and resolution before moving on to initialization.

• The entire process is referred to as the class loading process, with the class loader subsystem being responsible for these activities.

Error Handling During Class Loading

• If errors occur during loading, linking, or initialization, a java.lang.LinkageError is thrown as a runtime exception.

• A VerifyError is also noted as a subclass of LinkageError, indicating issues specifically during the verification phase.

Types of Class Loaders

Categories of Class Loaders

• There are three primary types of class loaders within the class loader subsystem:

• Bootstrap Class Loader (also known as Primordial Class Loader)

• Extension Class Loader

• Application Class Loader (or System Class Loader)

Responsibilities of Each Type

• Each type has distinct responsibilities regarding which classes they load. Understanding these differences is crucial for effective Java programming.

Bootstrap Class Loader Overview

Introduction to Bootstrap Class Loader

• The bootstrap class loader is responsible for loading core Java API classes, primarily from the rt.jar file.

• Core Java API classes such as String.class and StringBuffer.class are located within the rt.jar, which is essential for Java applications.

Location of rt.jar

• The rt.jar file is found in the JDK installation path under jdk/jre/lib, which is considered the bootstrap class path.

• This location serves as the default bootstrap class path where all necessary core classes are loaded by the bootstrap class loader.

Implementation Details

• The bootstrap class loader is not implemented in Java; instead, it is developed using native languages like C or C++.

• It specifically loads core Java API classes from the rt.jar, ensuring that fundamental components of Java are available during runtime.

Understanding Class Paths and Loaders

Bootstrap Class Path Definition

• The term "bootstrap class path" refers to the specific location where core classes are stored, namely in rt.jar.

• The bootstrap class loader's primary function is to load these classes from this designated path into memory for execution.

Availability and Characteristics

• Every JVM (Java Virtual Machine) comes with a default implementation of the bootstrap class loader.

• Its implementation in native languages highlights its foundational role in initializing Java applications before any user-defined code runs.

Extension Class Loader Insights

Role of Extension Class Loader

• The extension class loader loads classes from an extension class path, which includes libraries found in a specific directory structure within JDK.

• This extension library (lib/ext) contains additional libraries that can be utilized by Java applications beyond those provided by core APIs.

Hierarchical Structure of Loaders

• The extension class loader acts as a child of the bootstrap class loader, inheriting its properties while extending functionality to load additional libraries.

• Classes located within this extension path are loaded specifically by the extension class loader when required during application execution.

Implementation and Functionality

Implementation Details of Extension Class Loader

• Unlike the bootstrap class loader, which relies on native implementations, the extension class loader is implemented directly in Java.

• It utilizes a specific internal structure (sun.misc.Launcher$ExtClassLoader) to manage loading operations effectively.

This structured approach provides clarity on how different types of loaders operate within the JVM ecosystem, emphasizing their roles and relationships.

Understanding Java Class Loaders

What is the Dollar Symbol in Class Names?

• The presence of a dollar symbol ($) in a class file name indicates that it is an inner class within an outer class. This concept is crucial for understanding Java's object-oriented structure.

Types of Class Loaders

Bootstrap Class Loader

• The Bootstrap Class Loader is the first class loader in Java, responsible for loading core classes from the bootstrap class path. It serves as the foundation for other loaders.

Extension Class Loader

• The Extension Class Loader loads classes from the extension directory and acts as a child to the Bootstrap Class Loader. It plays a vital role in managing additional libraries and extensions.

Application (System) Class Loader

• The Application or System Class Loader is responsible for loading classes from the application class path, which is defined by the environment variable CLASSPATH. It inherits from the Extension Class Loader, making it its child.

Loading Mechanism of Application Class Loader

• The Application Class Loader uses the environment variable CLASSPATH to locate and load classes, ensuring that all necessary application components are available during runtime. This loader specifically targets user-defined classes and libraries.

Corresponding Do-Class File Names

• Each type of class loader has corresponding .class files:

• For example, sun.misc.Launcher$Ext.class corresponds to the Extension Class Loader.

• Similarly, sun.misc.Launcher$App.class relates to the Application Class Loader, highlighting how these loaders are implemented in Java.

Summary Diagram of Java's Class Loaders

• A diagram illustrating relationships among different class loaders can enhance understanding:

• Bootstrap → Extension → Application (System)

• This hierarchy shows how each loader builds upon its predecessor, emphasizing their roles in loading Java applications effectively.