Thoroughly Confused about ClassLoading in JAVA

[sandeeprajsingh tandon]

Hi,

I went through some online tutorials but am very confused at the concept
1) Primordial Class Loader: One which loads java Core classes
2) Extenstions Class Loader: Loads from lib/extn external libraries
3) System Class Loader: Loads from classpath

Now,
My Questions
A) Why are 1 and 2 being called as USERDEFINED Classloaders.
B) Now, some tutorial also said, "We can also get a ClassCastException when two different class loaders load the same class because they
are treated as two different classes."
Now, Why will 2 class loaders ever load same class. Can some one give me an example.

Thanks
Sandeep

[Rob Spoor]

B) Consider this little example of dynamic loading:

public List getListFromJAR(URL jar, String className) throws Exception
{
    ClassLoader loader = new URLClassLoader(new URL[] {jar});
    Class<?> cls = Class.forName(className, true, loader);
    return (List)cls.newInstance();
}

If the JAR is not part of the class path and the class cannot already be found by the thread's current class loader, two distinct calls to the same method with the same parameters still lead to different classes. Although both list classes will be loaded from the same .class file they are still unequal.

[sandeeprajsingh tandon]

Rob,
I am not really at home with the concepts of classloading even after reading many tutorials.
I will be really thankful if you can help me understand,

When i write a class as an application developer, the compiled class "MyClass" goes into the classpath . System ClassLoader should automatically load that class when needed.

Is my above understanding correct?

Now when you say
"If the JAR is not part of the class path" : Then where do you see it lying?
"and the class cannot already be found by the thread's current class loader" : Which is the threads current class Loader and why was it not found by that class loader,
"two distinct calls to the same method with the same parameters still lead to different classes," : Hence i didnt understand this quote of yours.

Thanks
Sandeep

[Rob Spoor]

sandeeprajsingh tandon wrote:When i write a class as an application developer, the compiled class "MyClass" goes into the classpath . System ClassLoader should automatically load that class when needed.

Is my above understanding correct?

Correct.

Now when you say
"If the JAR is not part of the class path" : Then where do you see it lying?

The most often used example is with plugins. The user should be able to add plugins without recompiling the application, and in an ideal situation also without having to modify the class path. Just let him put the JAR file in a specific folder, load that JAR file with a URLClassLoader, then load the class. Or in an even more generic way, let the user specify the location of the JAR file without having to copy it. The JAR file can even be located on some web server!

"and the class cannot already be found by the thread's current class loader" : Which is the threads current class Loader and why was it not found by that class loader,

Each thread can have its own class loader. By default it's the system class loader but with Thread.setContextClassLoader you can change it.

Now consider again the plugin example. My thread's current class loader is still the system class loader. The JAR file is not in the class path. That means that the thread's class loader cannot find the class. That's why you use a URLClassLoader.

"two distinct calls to the same method with the same parameters still lead to different classes," : Hence i didnt understand this quote of yours.

Two Class objects are equal if they have the same name and are loaded by the same class loader. In my example both classes have the same name, but each is loaded using a newly created class loader. Therefore, even though both Class objects have the same name and come from the same JAR file, they are still not equal.

[sandeeprajsingh tandon]

Hi Rob,

"Now consider again the plugin example. My thread's current class loader is still the system class loader. The JAR file is not in the class path. That means that the thread's class loader cannot find the class. That's why you use a URLClassLoader. "

Rob, In your example, you have used URLCLASSLOADER. Now, when the developer writes that piece of code that you are writing, shouldnot he know prior, that he has to use a URLCLASSLOADER because he is asking things from JAR outside Classpath.?

If what i say is true, then is it only a programming mistake that will cause 2 classloaders to load 1 class?

So, what i am confused on is is there an actual case in point where 2 classloaders would ever try to snatch each others responsibilities


I hope my doubt is clear

[Rob Spoor]

sandeeprajsingh tandon wrote:If what i say is true, then is it only a programming mistake that will cause 2 classloaders to load 1 class?

I don't know if I would call it a programming mistake. It most definitely is odd design yes.

So, what i am confused on is is there an actual case in point where 2 classloaders would ever try to snatch each others responsibilities

To be honest, I've never had this happening. Web containers like Tomcat use multiple class loaders (one for each web application) but the code from one web app cannot directly communicate with the code from another app, so even though there may be two versions of the same class (because both web apps have the same JAR file in their lib file), these classes can never "meet".

[sandeeprajsingh tandon]

Thanks Rob for your time.

As you said, there is hardly any chance when there would a case of class snatching between 2 classloaders.
May be for the tomcat incident that you say, Class Loading confusion is a problem when just just MAY BE..., when accidently some one has 2 versions of the same 3rd party library that 2 applications are using.
All applications deployed on 1 tomcat and communicating to each other.


So as an application developer, i almost never to worry about Class loading if i am following good working rules of application development using an IDE.
Regards,
Sandeep