Why is the setContextClassLoader() method placed on Thread?

Why is the setContextClassLoader() method placed on Thread?

What different thread have different classloaders?

The question is what if I extended a ClassLoader, loaded there some new classes. to the my custom classloader.

Now , I want it to be the context classloader , so I call the method Thread.currentThread().setContextClassLoade开发者_运维技巧r(loader).

Are these new classes awailable only in the context of the current thread ? Or how does it work?

Thanks

---

The Context class loader is the class loader that the thread will use to find classes. You primarily care about this when you are writing an application server or something similar. The idea is that you can start a thread from a class loaded in the application server's class loader, and yet pass it a child class loader that handles loading the classes of the deployed application.

---

The thread context class loader is a little bit of a hack.

When you load a class with reflection, you use either an explicit class loader or the one of the immediate calling class. When you link to a class using normal Java code, then class requesting the linking is used as the source for the loader.

Thread.setContextClassLoader is used to set the class loader for Thread.getContextClassLoader. This is used by random APIs (notably through ServiceLoader) to pick up classes through reflection so that you can change implementation. Having implementations change out from under your code depending upon which thread it is running on at a crucial moment is a bad idea.

---

Thread.setContextClassLoaderis used to set contextClassLoader, if not set manually, it will set to systemClassLoader which is Launcher.AppClassLoader ,this can be proved by checking the source code of Launcher.

Then what is the use of contextClassLoader?

contextClassLoader provides a back door around the classloading delegation scheme.

Then this question becomes why do we need this back door?

From the JavaWorld article Find a way out of the ClassLoader maze

Take JNDI for instance: its guts are implemented by bootstrap classes in rt.jar (starting with J2SE 1.3), but these core JNDI classes may load JNDI providers implemented by independent vendors and potentially deployed in the application's -classpath. This scenario calls for a parent classloader (the primordial one in this case) to load a class visible to one of its child classloaders (the system one, for example). Normal J2SE delegation does not work, and the workaround is to make the core JNDI classes use thread context loaders, thus effectively "tunneling" through the classloader hierarchy in the direction opposite to the proper delegation.

---

Java class loaders can be classified into below categories

1) Bootstrap Class Loader
Load classes from JAVA_HOME/jre/lib/rt.jar

2) Extensions Class Loader<
Load classes from JAVA_HOME/jre/lib/ext

3) System Class Loader
Classpath of the application

We can create own class loader and specify own location from which classes can be loaded , that is refer to ContextClassLoader

Hope that gives idea upon why we need to use setContextClassLoader()