DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Classloaders in JVM: An Overview
  • Java and Low Latency
  • JVM Tuning Using jcmd
  • Java Virtual Threads and Scaling

Trending

  • Is Agile Right for Every Project? When To Use It and When To Avoid It
  • Event-Driven Architectures: Designing Scalable and Resilient Cloud Solutions
  • Testing SingleStore's MCP Server
  • Automating Data Pipelines: Generating PySpark and SQL Jobs With LLMs in Cloudera
  1. DZone
  2. Coding
  3. Java
  4. Java Virtual Machine Internals, Part 1: Class Loader

Java Virtual Machine Internals, Part 1: Class Loader

Want to learn more about JVM internals? Here's a look at the class loader.

By 
Prateek Saini user avatar
Prateek Saini
·
Updated Jul. 11, 19 · Presentation
Likes (19)
Comment
Save
Tweet
Share
42.0K Views

Join the DZone community and get the full member experience.

Join For Free

The Java Virtual Machine is the heart of the Java ecosystem. Thanks to the JVM, when it comes to Java programs, we can 'write once, run everywhere.' Like other virtual machines, the JVM is also an abstract computer. The Java Virtual Machine's main job is to load class files and execute the bytecode they contain.

There are multiple components of the Java Virtual Machine like class loader, the garbage collector (automatic memory management), interpreter, JIT compiler, thread management. In this series,  I’ll be discussing how the Java Virtual Machine works. In this first installment, we are going to talk about the class loader. So let's get started!

The class loader loads class files from both the program and the Java API. Only those class files from the Java API that are actually needed by a running program are loaded into the virtual machine.

The bytecodes are executed in an execution engine.

Image title

What Is Class Loading?

Class loading is finding and loading types (classes and interfaces) at runtime dynamically. Types data are contained in binary files in class file format.

Phases of Class Loading

The class loader subsystem is responsible for more than just locating and importing the binary data for classes. It must also verify the correctness of imported classes, allocate and initialize memory for class variables, and assist in the resolution of symbolic references. These activities are performed in a strict order:

  • Loading: finding and importing the binary data for a type with a particular name and creating a class or interface from that binary representation.
  • Linking: performing verification, preparation, and (optionally) resolution
  • Verification: ensuring the correctness of the imported type
  • Preparation: allocating memory for class variables and initializing the memory to default values
  • Resolution: transforming symbolic references from the type into direct references.
  • Initialization: invoking Java code that initializes class variables to their proper starting values.

Note: In addition to loading classes, a class loader is also responsible for locating resources. A resource is some data (a ".class" file, configuration data, or an image for example) that is identified with an abstract '/'-separated path name. Resources are typically packaged with an application or library so that they can be located by code in the application or library.

The Java Class Loading Mechanism

The Java platform uses a delegation model for loading classes. The basic idea is that every class loader has a "parent" class loader. When loading a class, a class loader first "delegates" the search for the class to its parent class loader before attempting to find the class itself.

The class loader delegation model is the graph of class loaders that pass loading requests to each other. The bootstrap class loader is at the root of this graph. Class loaders are created with a single delegation parent and look for a class in the following places:

  • Cache
  • Parent
  • Self

A class loader first determines if it has been asked to load this same class in the past. If so, it returns the same class it returned last time (that is, the class stored in the cache). If not, it gives its parent a chance to load the class. These two steps repeat recursively and depth first. If the parent returns null (or throws a ClassNotFoundException), then the class loader searches its own path for the source of the class.

Because the parent class loader is always given the opportunity to load a class first, the class is loaded by the class loader nearest the root. This also has the effect of only allowing a class loader to see classes loaded by itself or its parent or ancestors; it cannot see classes loaded by its children.

The Java SE Platform API historically specified two class loaders:

  • Bootstrap class loader: which loads classes from the bootstrap class path.

  • System class loader: which is the default delegation parent for new class loaders and, typically, the class loader used to load and start the application.

Run-Time Built-in Class Loaders (JDK 9+)

  • Application class loader: The application class loader is typically used to define classes on the application class path. It's default loader for JDK modules that provide tools or export tool APIs.

  • Platform class loader: It is selected (based on security/permissions) by Java SE and JDK modules. For e.g. java.sql

  • Bootstrap class loader: It defines the core Java SE and JDK modules.

The three built-in class loaders work together to load classes as follows:

  • The application class loader first searches the named modules defined to all of the built-in loaders. If a suitable module is defined as one of these loaders, then that loader will load the class. If a class is not found in a named module defined to one of these loaders, then the application class loader delegates to its parent. If a class is not found by its parent, then the application class loader searches the class path. Classes found on the class path are loaded as members of this loader's unnamed module.
  • The platform class loader searches the named modules defined to all of the built-in loaders. If a suitable module is defined as one of these loaders, then that loader will load the class. If a class is not found in a named module defined to one of these loaders, then the platform class loader delegates to its parent.
  • The bootstrap class loader searches the named modules defined to itself. If a class is not found in a named module defined to the bootstrap loader, then the bootstrap class loader searches the files and directories added to the bootstrap class path via the -Xbootclasspath/a option (allows files and directories to be appended to the default bootstrap class path now). Classes found on the bootstrap class path are loaded as members of this loader's unnamed module.

To see the built-in class loaders, you can run the below code:

public class BuiltInClassLoadersDemo {

    public static void main(String[] args) {
        BuiltInClassLoadersDemo demoObject = new BuiltInClassLoadersDemo();
        ClassLoader applicationClassLoader = demoObject.getClass().getClassLoader();
        printClassLoaderDetails(applicationClassLoader);

        // java.sql classes are loaded by platform classloader
        java.sql.Date now = new Date(System.currentTimeMillis());
        ClassLoader platformClassLoder = now.getClass().getClassLoader();
        printClassLoaderDetails(platformClassLoder);

        // java.lang classes are loaded by bootstrap classloader
        ClassLoader bootstrapClassLoder = args.getClass().getClassLoader();
        printClassLoaderDetails(bootstrapClassLoder);
    }

    private static void printClassLoaderDetails(ClassLoader classLoader){
        // bootstrap classloader is represented by null in JVM
        if(classLoader != null) {
            System.out.println("ClassLoader name : " + classLoader.getName());
            System.out.println("ClassLoader class : " + classLoader.getClass().getName());
        }else {
            System.out.println("Bootstrap classloader");
        }
    }
}


With Amazon Corretto 11.0.3 installed on my machine, the above code produces the following output:

ClassLoader name : app
ClassLoader class : jdk.internal.loader.ClassLoaders$AppClassLoader 
ClassLoader name : platform 
ClassLoader class : jdk.internal.loader.ClassLoaders$PlatformClassLoader 
Bootstrap classloader


You can check the ClassLoader APIs here (JDK 11).

Note: HotSpot VM (via Amazon Corretto 11 ) is used as reference JVM implementation in this series. 

Stay tuned for part 2 where we take a closer look at JVM internals and the class file format.

Loader (equipment) Java virtual machine Java (programming language) Virtual Machine Machine

Opinions expressed by DZone contributors are their own.

Related

  • Classloaders in JVM: An Overview
  • Java and Low Latency
  • JVM Tuning Using jcmd
  • Java Virtual Threads and Scaling

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!