Class loading in JAVA

Even classes are objects!

Class Loading in JAVA may seem a very known concept. But it took a lot of effort to build what today is one of the major part of the Java Virtual Machine (JVM).

Class and Data

Java running environment works around two terms “class” and “data”. A class represents the code to be executed while the data

represents the state associated to the code. But there is not much difference between the two actually.A class usually has its code contained in a .class file. Every class will have its code available in the form of a JAVA object which is an instance of [java.lang.Class].

Whenever a java file is compiled, the JVM embeds a public, static, final

field named “class” of the type [java.lang.Class] in the bytecode. Since this field is public we can access it from anywhere.

  .....   .....   java.lang.Class clazz = MyClass.class;   ..... }

Once a class is loaded into the JVM, the same class will not be loaded again (Well, this implementation can be changed though by implementing custom class-loaders). In Java, a class is identified by its fully qualified name i.e. its package name + the class name

. But a class is uniquely identified in a JVM using its fully qualified class name along with the instance of the ClassLoader that loaded the class.

If a class-loader CL1 loaded MyClass then JVM stores its entry as (CL1.PKG1.MyClass) and if class-loader CL2 also loaded MyClass then JVM stores it entry as (CL2.PKG1.MyClass).Well this might be confusing. More than one class-loader. The next section will clear all your doubts.

Class Loader

In JVM, every Class is loaded by some instance of [java.lang.ClassLoader].Whenever a new JVM is started by launching “java <classname>” command, the first step is to load all the key classes in memory required for proper working like [java.lang.Object] and other runtime classes (rt.jar).The BootstrapClassLoader is responsible for making these classes available i.e. loading these important classes in memory.

The next task is to load any external libraries / JARs into the memory for proper working of the application. The ExtClassLoader is responsible for this task. This class loader is responsible for loading all the .jar files mentioned in java.ext.dirs path.

The third and the main important class loader is the AppClassLoader. The application class loader is responsible for loading of the class files mentioned in the java.class.path system property.

Below are a few class loaders in the JDK.

• java.net.URLClassLoader
• java.security.SecureClassLoader
• java.rmi.server.RMIClassLoader
• sun.applet.AppletClassLoader

The main advantage of having multiple class loaders is that we can have different versions of the same library / application in the JVM for use.

Working

Figure 1 shows an application with a main class called MyMainClass. As explained earlier MyMainClass will be loaded by the AppClassLoader. MyMainClass creates instances of two class loaders, CustomClassLoader1 and CustomClassLoader2, which are capable of finding the byte codes of a fourth class called Target from some source (say, from a network path). This means the class definition of the Target class is not in the application class path or extension class path. In such a scenario, if MyMainClass asks the custom class loaders to load the Target class, Target will be loaded and Target.class will be defined independently by both CustomClassLoader1 and CustomClassLoader2

if Target class is loaded by both loader1 and loader2, their fully qualified name will be [CL1, mypackage, Target] and [CL2, mypackage, Target]. Since both the instances of Target class i.e. target1 and target2 were loaded by different class loaders, they are type-incompatible. In other words, JVM will throw ClassCastException

  .....   Target target1 = (Target) target2; // throws ClassCastException     .....   .....}

This exception is thrown as JVM sees these two having different class types. Hope basic idea of class loading is clear.

I would recommend you to read about Just in Time Compilers