JVM,Part2

 ClassLoading in Java 

Classloading in Java is achieved by an entity called the Classloader.

A Classloader takes in the raw bytes from a .class file , standard Java api's provided with the SDK (or) any other custom classes required by class file and then creates the right bytecodes to run  .class file

1. • The ClassLoader: It takes care of finding and loading the types( class, interface , enum  and Annotation) in class loader subsystem.
   • There are two types of class loader: Bootstrap class loader and User defined class loader or also called as Custom class loader
     • Bootstrap class loader is provided by the vendor which implements the abstract specification of the JVM.
     • User-defined class loaders or custom loader are the part of running java application. Classes loaded by different class loaders which are placed into separate namespaces inside JVM.
     • user-defined class loaders are regular Java objects whose class extend from java.lang.ClassLoader.For every type a Java virtual machine loads, it creates an instance of class java.lang.Class to represent that type. Like all objects, user-defined class loaders and instances of class Class reside on the heap. Data for loaded types resides in the method area.
        
   The class loader subsystem deals with three steps process:
   1) Loading: In loading process the class loader subsystem finds and brings the binary data required by the type into JVM. Means read the .class bytes into the JVM process memory
   
   
   2) Linking: In Linking process binary type data is incorporated into the runtime state of the virtual machine. It involves three process:   
   
   
   
   
   
   
   
   • Verification: the binary data imported for the type being loaded is correct or not. 
   • Preparation: it involves building up JVM internal data structures to store the class entities in a way the JVM finds .The preparation phase allocates the memory needed by the type like memory for class variables and memory are initializes with the default values.
   • Resolution: It is the process of transforming symbolic references in the constant pool into direct references. After verification, preparation, and (optionally) resolution are completed, the type is ready for initialization. the previous step had built up the data structures with relative offsets and symbol references - in this step we "resolve"
   • These three steps mean to be happen in order. Only exception condition may be resolution step which can occur after initialization.
    

  ClassLoader in java

1) Every Java virtual machine implementation has a bootstrap class loader, which knows how to load trusted classes, including the classes of the Java API. The Java virtual machine specification doesn't define how the bootstrap loader should locate classes.

2) The bootstrap loader looks in each directory, in the order the directories appear in the CLASSPATH, until it finds a file with the appropriate name: the type's simple name plus ".class". Unless the type is part of the unnamed package, the bootstrap loader expects the file to be in a subdirectory of one the directories in the CLASSPATH. The path name of the subdirectory is built from the package name of the type. For example, if the bootstrap class loader is searching for class java.lang.Object, it will look for Object.class in the java\lang subdirectory of each CLASSPATH directory.

3) BootStrap classloader Loads JDK internal classes, java.*packages. (as defined in the sun.boot.class.path system property, typically loads rt.jar and i18n.jar).

4)  Apart from this there is extension class loader which Loads jar files from JDK extensions directory (as defined in the java.ext.dirs system property – usually lib/ext directory of the JRE)

5)   In Java 2 SDK virtual machine, searching the class path is the job of the system class loader, a user-defined class loader that is created automatically when the virtual machine starts up.

6) System class loader Loads classes from system classpath (as defined by the java.class.path property, which is set by the CLASSPATH environment variable or –classpath or –cp command line options)

The class loader follows the delegation model where All , except the bootstrap ClassLoader, must have a parent -.

Bootstrap
  
Extension
  
Application
  
UserdefinedCL1 , UserdefinedCL2

What is delegation model?

The delegation model requires that any request for a class loader to load a given class is first delegated to its parent class loader before the requested class loader tries to load the class itself. The parent class loader, in turn, goes through the same process of asking its parent. This chain of delegation continues through to the bootstrap class loader (also known as the  system class loader). If a class loader's parent can load a given class, it returns that class. Otherwise, the class loader attempts to load the class itself.

Consider an example:  Say you have your own implementation of java.lang.String class.
Place it in the classpath Run your app, say, HelloWorld, with a custom classloader MyClassloader to load the String class Without parent delegation: you could probably force the classloading of your own implementation, rather than the more trusted one which comes with the SDK. In which case the chances of crashing the JVM rises from 99-100% With parent delegation: JVM go on with its usual business of asking bootstrap to load it from the RIGHT jar.

                        --MORE TO COME, KEEP VISITING