Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
June 6, 2003
When should I use
Although not frequently asked, this question is rather tough to correctly answer. It usually comes up during framework programming, when a good deal of dynamic class and resource loading goes on. In general, when loading a resource dynamically, you can choose from at least three classloaders: the system (also referred to as the application) classloader, the current classloader, and the current thread context classloader. The question above refers to the latter. Which classloader is the right one?
One choice I dismiss easily: the system classloader. This classloader handles
-classpath and is programmatically accessible as
ClassLoader.getSystemXXX() API methods are also routed through this classloader. You should rarely write code that explicitly uses any of the previous
methods and instead let other classloaders delegate to the system one. Otherwise, your code will only work in simple command-line
applications, when the system classloader is the last classloader created in the JVM. As soon as you move your code into an
Enterprise JavaBean, a Web application, or a Java Web Start application, things are guaranteed to break.
So, now we are down to two choices: current and context classloaders. By definition, a current classloader loads and defines
the class to which your current method belongs. This classloader is implied when dynamic links between classes resolve at
runtime, and when you use the one-argument version of
Class.getResource(), and similar methods. It is also used by syntactic constructs like
X.class class literals (see "Get a Load of That Name!" for more details).
Thread context classloaders were introduced in Java 2 Platform, Standard Edition (J2SE). Every
Thread has a context classloader associated with it (unless it was created by native code). It is set via the
Thread.setContextClassLoader() method. If you don't invoke this method following a
Thread's construction, the thread will inherit its context classloader from its parent
Thread. If you don't do anything at all in the entire application, all
Threads will end up with the system classloader as their context classloader. It is important to understand that nowadays this is
rarely the case since Web and Java 2 Platform, Enterprise Edition (J2EE) application servers utilize sophisticated classloader
hierarchies for features like Java Naming and Directory Interface (JNDI), thread pooling, component hot redeployment, and
Why do thread context classloaders exist in the first place? They were introduced in J2SE without much fanfare. A certain lack of proper guidance and documentation from Sun Microsystems likely explains why many developers find them confusing.
In truth, context classloaders provide a back door around the classloading delegation scheme also introduced in J2SE. Normally, all classloaders in a JVM are organized in a hierarchy such that every classloader (except for the primordial classloader that bootstraps the entire JVM) has a single parent. When asked to load a class, every compliant classloader is expected to delegate loading to its parent first and attempt to define the class only if the parent fails.