I have read that there are different class loaders in java, the one is primordial class loader and there are custom class loaders as well, so I want to understand why primordial class loader is not able to serve all classes in java? Why is there need for other class loaders?
-
2One advantage to having a smaller class-path for the first class loader is that it will be able to find classes faster. – Andrew Thompson Nov 28 '13 at 07:11
-
possible duplicate of [What is a java ClassLoader?](http://stackoverflow.com/questions/2424604/what-is-a-java-classloader) – Kayaman Nov 28 '13 at 07:12
6 Answers
The main need is isolation.
Let's say there are 3 applets on a page, each using a different version of the library foo.jar. You want each of those applets to run with its own version of the library, and to make sure it doesn't walk on another applet's toes. This is accomplished thanks to different class loaders.
The same goes for web applications deployed on a single container. The Java container is started without any app deployed, and then an app is deployed. You want the container to be able to load classes from a location it didn't even know about when it was started. And if another webapp is deployed, you want this other app to have its own classes and libraries, that are different and isolated from the classes and libraries of the first app.
Another need is to be able to load classes from various locations: the file system, but also URLs, databases, or whatever.

- 678,734
- 91
- 1,224
- 1,255
-
1Near-perfect answer IMO. I'd like to expand the need for isolation with the fact that by utilizing different classloaders you also resolve classpath-clashes, such as the multiple copies of the same classes existing within the same JVM but perhaps different versions to be used by different applications (ex: one application using Hibernate 3.x and another using Hibernate 4.x). – Gimby Nov 28 '13 at 09:14
There are many practical situations in which you want features beyond what the system class loader provides:
- You can give access to custom class sources (e.g., via http)
- You can cache blocks of data (e.g., 'if this class is needed, then let me pre-load these other classes')
- You can incorporate security protocols that prevent the loading of certain classes
- You can keep statistics of what classes are used, to later optimise your jar archives
- You can perform bytecode transformations ('load-time weaving') while loading the classes, e.g., to modify classes that fit a certain pattern. Aspect-Oriented Programming implementations can use this technique.
The final point is particularly powerful (and has been the main reason for why I have used them). Since Java bytecode is universal across platforms, you can use it to instrument classes on any system: measure which methods are called, suppress security-critical calls, divert System.out accesses to your own custom logging routines, or perform advanced dynamic bug-testing routines.

- 1,728
- 9
- 16
-
The latter points are usually done using Java Agents and the Instrumentation interface provided by them. Specific class loader implementations are usually not used for this. However nice answer, still +1 from me. – Matthias Nov 28 '13 at 07:25
One reason is security. For example, the default (package-private) visibility level allows access only to classes from the same package, and loaded by the same class loader. This makes it more difficult for malicious code to access your internal API.
References:

- 15,303
- 7
- 59
- 83
Suppose you are developing an application server. Based upon the requirements, you will like to load classes on server start-up. primordial loader is not aware of your requirement & hence you need to write your own class loader.

- 1,542
- 4
- 24
- 37
This answer sums up quite well why you might not want to use the same classloader for all classes even if you could:
ClassLoaders are used in large systems and server applications to do things like:
- Modularize a system and load, unload and update modules at runtime
- Use different versions of an API library (e.g. an XML parser) in parallel
- Isolate different applications running within the same JVM (ensuring they don't interfere with each other, e.g. through static variables)
Types of Class Loaders:
- Boot Strap Class loader/Premodial Class Loader
- Extension Class Loader
- Application Class Loader/System Class Loader
Boot Strap Class loader: Responsible to load core JAVA API classes i.e. the classes present in rt.jar
Location of rt.jar -> jdk/jre/lib/rt.jar which is also known as bootstrap class path.
Bootstrap class loader load classes from bootstrap class path. Bootstrap is implemented in native languages like C or C++, not implemented in JAVA.
Extension Class Loader: loads classes from extension class path i.e jdk/jre/lib/ext/*.jar
Extension class loader is child of BootStrapClassLoader and it is implemented in JAVA.
Corresponding JAVA Class is sun.misc.Launcher$ExtClassLoader.class
Application Class Loader: child class of Extension class loader. Application class loader loads classes from Application Class path. It internally uses environment class path.
Its implemented in JAVA. Corresponding JAVA Classes is sun.miscLauncher$AppClassLoader.class
Class loader follows Delegation Hierarchy Principle. Whenever JVM come across a particular class, first it will check where .class file is already loaded or not. If its already loaded in method area then JVM will consider that loaded class, if not JVM request Class Loader Subsystem to load particular class. Class Loader subsystem hand over request to application class loader, it delegates request to Extension Class loader then it delegates to BootStrap Class loader which searches the bootstrap class path, if not found, Extension Class loader search Extension class path, if not found then Application class laoder searches Application Class path, if the class is still not found then ClassNotFoundException or NoClassDefFoundError will occur.

- 1,580
- 15
- 12