A Java Virtual Machine (JVM) is a Virtual Machine capable of executing java byte code.
Loading is the process of finding the binary representation of a class or interface type with a particular name and creating a class or interface from that binary representation.
Loading: finding and importing the binary data for a type
There are two types of class loaders: user-defined class loaders and the bootstrap class loader supplied by the Java virtual machine. Every user-defined class loader is an instance of a subclass of the abstract class
Linking: performing verification, preparation, and (optionally) resolution
A class loader is an object that is responsible for loading classes. The class ClassLoader is an abstract class.
When the JVM is started, three class loaders are used
Bootstrap
The bootstrap class loader loads the core Java libraries[5] (
The extensions class loader loads the code in the extensions directories (
The system class loader loads code found on
Explanation:
When a new JVM instance is started , the bootstrap class loader is responsible for loading key java classes like java.lang.Object and other runtime code into memory. The runtime classes are packaged inside jre/lib/rt.jar file. We cannot find the details of the bootstrap class loader in the java language specification, since this is a native implementation. For this reason the behavior of the bootstrap class loader will differ across JVMs.
next comes the Extensions (Loads jar files from JDK extensions directory (as defined in the java.ext.dirs system property – usually lib/ext directory of the JRE) and then System (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) ClassLoaders.
Class loaders are hierarchical and use a delegation model when loading a class. Class loaders request their parent to load the class first before attempting to load it themselves. When a class loader loads a class, the child class loaders in the hierarchy will never reload the class again. Hence uniqueness is maintained. Classes loaded by a child class loader have visibility into classes loaded by its parents up the hierarchy but the reverse is not true
Creation and Loading
The Java virtual machine dynamically loads, links, and initializes classes and interfaces. Loading is the process of finding the binary representation of a class or interface type with a particular name and creating a class or interface from that binary representation.
Loading: finding and importing the binary data for a type
There are two types of class loaders: user-defined class loaders and the bootstrap class loader supplied by the Java virtual machine. Every user-defined class loader is an instance of a subclass of the abstract class
ClassLoaderLinking
Linking is the process of taking a class or interface and combining it into the runtime state of the Java virtual machine so that it can be executed.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
Initialization: invoking Java code that initializes class variables to their proper starting values.
Initialization of a class or interface consists of executing the class or interface initialization method<clinit>A class loader is an object that is responsible for loading classes. The class ClassLoader is an abstract class.
When the JVM is started, three class loaders are used
- Bootstrap class loader
- Extensions class loader
- System class loader
Default Class Loader Hierarchy
Bootstrap
The bootstrap class loader loads the core Java libraries[5] (
<JAVA_HOME>/lib directory). This class loader, which is part of the core JVM, is written in native code.The extensions class loader loads the code in the extensions directories (
<JAVA_HOME>/lib/ext or any other directory specified by the java.ext.dirs system property). It is implemented by the sun.misc.Launcher$ExtClassLoader class.The system class loader loads code found on
java.class.path, which maps to the system CLASSPATH variable. This is implemented by the sun.misc.Launcher$AppClassLoader class.Explanation:
When a new JVM instance is started , the bootstrap class loader is responsible for loading key java classes like java.lang.Object and other runtime code into memory. The runtime classes are packaged inside jre/lib/rt.jar file. We cannot find the details of the bootstrap class loader in the java language specification, since this is a native implementation. For this reason the behavior of the bootstrap class loader will differ across JVMs.
next comes the Extensions (Loads jar files from JDK extensions directory (as defined in the java.ext.dirs system property – usually lib/ext directory of the JRE) and then System (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) ClassLoaders.
Class loaders are hierarchical and use a delegation model when loading a class. Class loaders request their parent to load the class first before attempting to load it themselves. When a class loader loads a class, the child class loaders in the hierarchy will never reload the class again. Hence uniqueness is maintained. Classes loaded by a child class loader have visibility into classes loaded by its parents up the hierarchy but the reverse is not true
No comments :
Post a Comment