ClassLoader Delegation Mechanism

[Vaibhav Gargs]

As per my understanding, during execution of a program whenever some class is required to be loaded; Application Class Loader will request Extension Class Loader which in turn will request BootStrap ClassLoader to load the class. If the BootStrap ClassLoader is unable to load the class, then it will delegate it to Extension and so on. Please correct me if I am wrong.

I am just wondering why it start from bottom i.e. Application > Extension > Bootstrap? Why doesn't it start directly from BootStrap since it will first check if it can load the class or not?

[Stephan van Hulst]

Because if an application has a specific idea about where classes should be found, it needs to take precedence over the other class loaders. More specific loaders need higher precedence over less specific loaders.

[Vaibhav Gargs]

Thanks Stephan for the response. I am sorry but can you please explain with an example for better understanding.

[Matt Wong]

The reason for the order is simply based on security:

Imagine what would happen if you would had an classloader wich loads an additional class external - and this class itself needs some classes contained in java.lang or other standard java.x packages - wich not loaded until this point (its hard to find such a class cause theres so many going on when the vm starts up - a damn load of classes already loaded before yours is even touched) - what would happen if you put a custom class named java.lang.String in your local classpath? It would get loaded before the original internal java.lang.String from rt.jar is loaded - wich is something that could not allowed to happen. That's why each classloader first delegates up to the parent loader to handle loading before trying to load a class on its own. I don't know if there its even possible to trick around it - my guess is that this is one of the many internal secrets hardcoded into the native code.

HIH

[Campbell Ritchie]

You usually suffer an exception if you try to create a class with java.XXX as its package name outwith the rt.jar file. That is obviously caused by the class loader taking its responsibilities seriously, as MW describes.

[Paul Clapham]

Vaibhav Gargs wrote:I am just wondering why it start from bottom i.e. Application > Extension > Bootstrap? Why doesn't it start directly from BootStrap since it will first check if it can load the class or not?

Well, as you see the bootstrap class loader gets first try at loading the class. But once it's tried to do that and failed, what should it do instead? It knows nothing about the extension class loader or your application class loader or any other class loaders that might be active.

So the model of "Parent class loader, can you load this class? No? Then I will load it" proceeding in a recursive fashion is the simplest solution to that problem.

[Vaibhav Gargs]

Thank you all for your valuable inputs.

Suppose if we write one custom class say java.lang.Test and embed it into rt.jar. This class in turn plays around with core JRE classes since both will be loaded by bootstrap class loader and should be able to access each other. So, won't it be a security threat in that case?

[Paul Clapham]

Of course, if you can mess about with the contents of rt.jar then there's an unlimited number of ways you can introduce security threats.

[Vaibhav Gargs]

Thank you Paul.

Just wondering why do we need to customize classloaders? What is the usecase of this customization?

[Paul Clapham]

You want to customize classloaders so that you can control which classes get loaded. Yes, I know that's not very specific but that's because there are many use cases (not "the" use case) why you might want to control that.

[Vaibhav Gargs]

Thank you Paul once again That makes perfect sense.

One more thought: What is the use of parent first and parent last classloaders? I have seen these terms in app servers.

[Paul Clapham]

"Parent first" means the class loader will ask the parent to try loading a class before it loads the class itself. "Parent last" means the class loader will try to load a class itself before asking its parent to load the class.

[Vaibhav Gargs]

So, I hope the default mechanism for JVM is Parent First. Please correct me if I am wrong.

And, if we use Parent Last then shouldn't it lead to security issues? What will be the use cases of using Parent Last? Is it really recommended/used in industry?

[Paul Clapham]

Vaibhav Gargs wrote:So, I hope the default mechanism for JVM is Parent First. Please correct me if I am wrong.

Yes, that's right. And if you hadn't said that I was going to ask you which one corresponded with the default.

And, if we use Parent Last then shouldn't it lead to security issues? What will be the use cases of using Parent Last? Is it really recommended/used in industry?

Use case: "I don't like what the standard classes in Websphere do, I want to provide my own versions."

As for "is it used in industry", as you said, it's an option in some app servers. You should be able to draw a conclusion from that.

And security issues? All I know about that is that the security-breakers are far better at their jobs than I am, so I would never say that any action at all is free of security issues. But if you had any particular issues in mind, that could be worth discussing.

[Paul Clapham]

Actually, my personal reason for using parent-last classloading in Websphere was more like "Websphere is acting weird, let's try it by putting this jar file in your app and using parent-last classloading".

[Vaibhav Gargs]

Paul Clapham wrote:
And security issues? All I know about that is that the security-breakers are far better at their jobs than I am, so I would never say that any action at all is free of security issues. But if you had any particular issues in mind, that could be worth discussing.

Suppose we write a custom class say String.java and it is included in our classpath and we are using Parent Last class loader, then what will happen?

Also, we say that the same class can be loaded by two different class loaders, how is it possible?

[Paul Clapham]

Vaibhav Gargs wrote:Suppose we write a custom class say String.java and it is included in our classpath and we are using Parent Last class loader, then what will happen?

If you were thinking of a custom version of java.lang.String, you can't do that. The compiler won't let you. If you were thinking of gargs.vaibhav.String, then no problem. It isn't going to cause confusion with any other classes.

Also, we say that the same class can be loaded by two different class loaders, how is it possible?

A class can of course be loaded by any class loader at all. There's no mystery about that.