CODEWITHSUNDEEP
javaclassloaderurlclassloader
Lavish Kothari
Lavish Kothari

Reputation: 2331

ClassLoader in Java

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.

Upvotes: 0

Views: 302

Answers (2)

Thomas Kl&#228;ger
Thomas Kl&#228;ger

Reputation: 21640

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:

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

  2. 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.

  3. 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).

Upvotes: 1

Joe
Joe

Reputation: 1342

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".

Upvotes: 0

Related Questions