Java Programming: First steps with ClassLoaders

Java Programming: First steps with ClassLoaders

Lately my interest in ClassLoaders and in how they work has been growing. This has happened because I'm curious by nature always wanting to learn more about stuff I use, and because I've been quite interested in implementing a hot deploy feature.

Initially I was thinking in writing a massive single post but I chose to divide it in two posts. This is the first one which is about the java virtual machine class loaders, what they are, how they work and how to customize them. The second post will about hot deploy, what is it, what class loaders have to do with it - actually I'll answer this question at the end of this post - how to achieve it and some actual java code doing the trick.

Even though this will be an introduction to the subject - after all I'm just learning this new cool tricks - I hope it will be interesting to everyone.

Java Class Loaders

A Class Loader is an entity responsible to dynamically load into the java virtual machine (JVM) java bytecode transforming it in an actual java usable objects. In other words, a class loader object is one object that can read class files (java compiled files) and create a java.lang.Class Object from it.

The JVM default environment contains neither one nor two but actually three Class Loaders (which can be seen in the schematic at the right).

Each one of these classes loaders as a different purpose:

• The Bootstrap Class Loader, also known as the primordial class loader, is the only one written in native code - this means it's part of the JVM core instead of being an object in the java language - and is responsible to load the JVM core library which are found in JAVA_HOME/lib.
• The Extension Class Loader, is already a java object - an instance of sun.misc.Launcher$ExtClassLoader - and is responsible to load the extensions in JAVA_HOME/lib/ext and any other that is specified in the java.ext.dirs system property.
• The System Class Loader is also a java object - instance of sun.misc.Launcher$AppClassLoader - and is responsible to load the classes that are in the classpath.

When a new instance of an object is created here's what happens:

1. The loadClass(String name) method is invoked at the thread's context class loader (by default the System Class Loader)
2. The class loader tries different ways to find the class file happening one of two things:

• The class is found
• The bytecode is read and provided to the defineClass method
• Every other reference found in that bytecode will be also resolved using the findClass(String name) method
• A Class object is returned
• The class isn't found
• The task of loading into the JVM the class is delegates to the class loader's parent.

The delegation performs an important role in the loading process, when a class loader does not find a given class it delegates to its parent until the class is resolved or an exception is thrown a class loader always delegates the search of a given class to its parent - there are exceptions though, that will be seen in the 2nd part - and only if the class is not found tries to load it on its own. (correction by vinraj)

Once a certain instance of the class loader defines a class, that instance cannot redefine the same class again. Although another class loader, or even another instance of the same class loader, will be allowed to define the class.

This is an interesting fact about java class loaders, and it happens because the class loaders are part of class identification within the JVM. Normally for a beginner or the average intermediate java programmer a class is identified by it's package and class name, although the JVM also considers the class loader who has loaded it. This means that the JVM will see the same class loaded by different class loaders as actual different classes.

Let's use an example - picture in the left - for better understanding: executing D.getClass().equals(E.getClass()) would return true, although C.getClass().equals(D.getClass()) would return false even if C, D and E are instances of the same class file!

Even more interesting is that custom class loaders can easily be created by extending the java.lang.ClassLoader class.

Custom Class Loaders

Why should custom class loaders be created? Sometimes the class loaders that the JVM provides aren't enough. Below are listed some of the reasons that could lead to the creation of a new class loader:

1. Security
2. Non standard ways of retrieving class files
3. Dynamic generation
4. Hot deploy

• Security
  A simple example can be digital signed classes. Let's imagine a secure application where even the classes loaded into the JVM have to be trusted. Every class file would be signed using a public key system and the custom class loader would first check the signature before loading the class into the JVM.
  
  
• Non standard ways of retrieving class files
  Due to some strange reason instead of having classes in the file system or as a jar package, there was the need to have all the classes inside a single .tar.bz2 compressed file. A custom class loader could simply detect the special compressed files, unpack them on-the-fly and load the classes into the JVM
  
  
• Dynamic generation
  This is definitely an interesting idea because it's here where we realised that almost anything can really be done. When I say dynamic generation I mean loading non-existing classes into the JVM, not everyone will have use to this but it's still pretty interesting. While talking with m4ktub about class loading an interesting scenario regarding snipsnap was suggested, here's the idea:
  
  Snipsnap would have a new snip label called java. It could then be associated with a snip that would only contain java code. A custom class loader that snipsnap would use, could then load that snip, wrap the content in a java file compile it and load the class into the JVM.
  
  Definitely an interesting idea, maybe not that useful though! laugh
  
  
• Hot Deploy
  This is probably one of the main reasons that many reasons that some applications and frameworks create custom class loaders. The idea of hot deploy is to have a class loader that allows to load new bytecode versions of a class in runtime without the need of restarting the application. This topic will be covered in more depth in the next post, where the concept and an actual implementation will be presented.

That's all for this first part. Comments, questions and general ideas about this subject are more than welcome.