Flow of class loading for a simple program
I am just now beginning to learn the internal architecture of Java. I have roughly understood the concept of class loading which loads the required classes when jvm runs, ClassNotFoundException is thrown when a class is not found and specific class loader loads the classes referenced by the class.
Can someone please explain clearly the flow of class loading i.e. the sequence of bootstrap class loading and user-defined class loading in the sample Java code below.
import java.io.File;
public class Sample
{
public static void main(String[] args)
{
String fileName = "sample";
File file = new File(fileName);
file.isFile();
}
}
Also I learnt from a reference material that "classloader maintains the namespaces of the classes it loads". By namespaces, does that mean the literal names of the class? Also can someone please explain the implication/advantage of that?
You will run your Sample class as follows
> java Sample
for little magic, check out the output of-verbose:class option and you see tons of following lines..
[Opened C:\jdk1.6.0_14\jre\lib\rt.jar]
[Loaded java.lang.Object from C:\jdk1.6.0_14\jre\lib\rt.jar]
[Loaded java.io.Serializable from C:\jdk1.6.0_14\jre\lib\rt.jar]
[Loaded java.lang.Comparable from C:\jdk1.6.0_14\jre\lib\rt.jar]
.
.
.
.
.
.
[Loaded java.security.cert.Certificate from C:\jdk1.6.0_14\jre\lib\rt.jar]
[Loaded Sample from file:/D:/tmp/]
[Loaded java.lang.Shutdown from C:\jdk1.6.0_14\jre\lib\rt.jar]
[Loaded java.lang.Shutdown$Lock from C:\jdk1.6.0_14\jre\lib\rt.jar]
You see a bunch of classes from \jre\lib\rt.jar are loaded, much before your class is loaded by Bootstrap class loader (or Primordial ). These are the pre-requisite for running any Java program hence loaded by Bootstrap.
Another set of jars is loaded by Extension class loader. In this particular example, there was no need of any classes from the lib \jre\lib\ext hence its not loaded. But Extension class loader are specifically assigned the task of loading the classes from the extension lib.
EDIT: Apart from the standard platform java classes Sun/Oracle also provide a set of jars which are used to extend the platform's core API. The jars placed in the extension lib folder are automatically placed in the classpath and hence not needed to be included in classpath explicitly. Here is nice official article on the same topic.
Finally, your class Sample is loaded by Application class loader after Bootstrap and Extension have finished loading.
Classloader hierarchy
Whenever a new JVM is started the bootstrap classloader is responsible to load key Java classes (from java.lang package) and other runtime classes to the memory first. The bootstrap classloader is a parent of all other classloaders. Consequently, it is the only one without a parent.
Next comes the extension classloader. It has the bootstrap classloader as parent and is responsible for loading classes from all .jar files kept in the java.ext.dirs path–these are available regardless of the JVM’s classpath.
The third and most important classloader from a developer’s perspective is the system classpath classloader, which is an immediate child of the extension classloader. It loads classes from directories and jar files specified by the CLASSPATH environment variable, java.class.path system property or -classpath command line option.
ClassLoader Namespace
In Java a class is uniquely identified using
ClassLoader + Class as the same class may be loaded by two different class loaders.
Class A loaded by ClassLoader A != Class A loaded by ClassLoader B
How is it helpful?
It is helpful for defining different protection and access policies for different classloaders. Take an example of applet which is loaded using a different classloader, you would not want a third party application all access to your resources. So for security its important to maintain different namespaces.
JVM maintains a runtime pool in permgen area where classes are loaded. Whenever a class is referenced default class loader finds the class in the class path and loads it into this pool. And this is not specific to user defined classes or classes provided in JDK. When a class is referenced it is loaded into the memory.
Classes loaded by the ClassLoader are stored internally in the ClassLoader instance
// The classes loaded by this class loader. The only purpose of this table
// is to keep the classes from being GC'ed until the loader is GC'ed.
private final Vector<Class<?>> classes = new Vector<>();
When class needs to be added to the memory following function is called:
// Invoked by the VM to record every loaded class with this loader.
void addClass(Class c) {
classes.addElement(c);
}
Found a useful diagram on how Class Loaders work.
The Java Virtual Machine starts up by creating an initial class, which is specified in an implementation-dependent manner, using the bootstrap class loader (§5.3.1). The Java Virtual Machine then links the initial class, initializes it and the static instance variables declared in it and finally invokes the public class method void main(String[]). The invocation of this method drives all further execution. Execution of the Java Virtual Machine instructions constituting the main method may cause linking (and consequently creation) of additional classes and interfaces, as well as invocation of additional methods.
read this link
The loading process can be viewed as interaction between Classloader Subsystem and the Memory Area of JVM.
Classloader works in three general steps 1.) Loading 2.) Linking and 3.) Initialization.
The very basic interaction between Classloader Subsystem and the Memory Area happens during Linking (apart from other interactions!)
Linking activity is subdivided into i.) Verify ii.) Prepare and iii.) Resolve. Verify: is more for security, valid compilation is checked. In the step ii.) Prepare - static variable memory is allocated and assigned with default values. And in
iii.) Resolve: Symbolic references are replaced with original references from the "Method Area" which contains class level data and static variables.
JVM Arch