ClassLoader in Java

Question

I was playing with classloaders in java and found the following behavior. I could logically reason out about this, but I'm not sure what I'm assuming is completely true. I'd like to know more formal explanation of this behavior.

What I was trying? So I had the following code:

URL[] classURLs = {new URL("file://C:/Users/HP/IdeaProjects/test/out/production/test/")};
URLClassLoader urlClassLoader = new URLClassLoader(classURLs, null);
Class<?> personClass = urlClassLoader.loadClass("com.test.Person");

// the following line will give a ClassCastException
Person p = (Person) personClass.getDeclaredConstructor().newInstance();

Now the last line gives me a ClassCastException.

My reasoning (guess) about why I'm getting a ClassCastException: The classloader of personClass is urlClassLoader whereas the classloader of Person class is actually application class loader or system class loader (please correct me if I'm wrong). These class loaders don't match and I'm getting a ClassCastException. (I'm here assuming that when typecasting a check is performed on the classloaders)

So now I continue exploring and alter the construction of URLClassLoader in the following way:

URLClassLoader urlClassLoader = new URLClassLoader(classURLs, Main.class.getClassLoader());

Here Main is the enclosing class. The above line saves me from a ClassCastException.

My reasoning (guess) about this: As now the urlClassLoader has application class loader as its parent (this application class loader is same that is used to load Person class), while trying to cast, Java check if the classloaders match and this check continues with the parent of the urlClassLoader, after going one step up the classloaders match and there is no ClassCastException.

I assume that the classloader of the class of the object to be typecasted is checked against the classloader of the class into which you need to typecast and if this don't match the parent of the classloader of the class of object is tried for the match and this continues.

Please correct me if I'm wrong at any point and also provide pointers to the formal documentation of this behavior.

I have seen this link, but this don't provide the details I've asked.

Possible duplicate of [cast across classloader?](https://stackoverflow.com/questions/2591779/cast-across-classloader) — MTCoster, Nov 19 '18 at 17:59
Read [this](https://zeroturnaround.com/rebellabs/rebel-labs-tutorial-do-you-really-get-classloaders/) For JVM same class but loaded with the different class loaders - are two different types. It have advantages like - using two different version of the same library in the same program, and solve the [JAR hell](https://dzone.com/articles/what-is-jar-hell). [OSGI](https://en.wikipedia.org/wiki/OSGi) frameworks using this feature, as well as Java 9+ modules. — Victor Gubin, Nov 19 '18 at 18:02
@MTCoster: I've seen [this](https://stackoverflow.com/questions/2591779/cast-across-classloader). But this don't explain whether what I'm thinking is correct or not. Specifically about the hierarchy comparison of classloaders — Lavish Kothari, Nov 19 '18 at 18:09
`Person p = (Person) ...` will use the `Person` version loaded by the application classloader at application start. By nulling out the classloader on the `URLClassLoader` you basically prevent urlClassloader from looking up the person class already loaded and force it to load its own version. On returning the newly created instance, let's say `objPerson#UrlCL`, a cast to `objPerson#AppCL` is forced which fails as notably the object was loaded by a different CL. Basically `A#CL1 != A#CL2` applies here — Roman Vottner, Nov 19 '18 at 18:30

score 1 · Answer 1 · edited Jun 20 '20 at 09:12

The formal documentation for the behaviour that you observe is in the ClassLoader#loadClass() documentation:

Loads the class with the specified binary name. The default implementation of this method searches for classes in the following order:

Invoke findLoadedClass(String) to check if the class has already been loaded.

Invoke the loadClass method on the parent class loader. If the parent is null the class loader built-in to the virtual machine is used, instead.

Invoke the findClass(String) method to find the class.

If you specify a parent class loader your URLClassLoader checks the parent class loader for the class before trying to load the class itself, which means that it will find the class from your application class path.

So if you set the parent class loader, this line:

Class<?> personClass = urlClassLoader.loadClass("com.test.Person");

behaves the same as

Class<?> personClass = Main.class.getClassLoader().loadClass("com.test.Person");

if the class com.test.Person is available on the application class loader (which it must be, otherwise your Main class cannot be loaded).

score 0 · Answer 2 · answered Nov 19 '18 at 18:11

You are loading the classes dynamically, thus, since you're able to compile class "Person", it means you're loading the same class twice, resulting in class cast exception.

Remove the library from your classpath and you won't get this error however, you also will loose access to the Person object.

Its still there when you load it, but the way to access it would be via Reflection, and you'll have to store the "Person" object as an "Object".

ClassLoader in Java

2 Answers2