What is the reason for having 3 classes of loaders in Java

Question

There are 3 class loaders in Java:

• Bootstrap
• Expansion and
• System

and they have one role; loading classes from different packages.

But why does Java have 3 different class loaders, and not just one, since a single class loader can load all the necessary classes?

Answer 1

The reason for having three basic class loaders (Bootstrap, extension, system) is mainly security.

Prior to version 1.2, the JVM had only one default class loader, which is currently called the Bootstrap class loader.

The path of classes loaded by class loaders is that each class loader first calls its parent, and if this parent does not find the requested class, the current one searches for it.

The key concept is the fact that the JVM will not provide access to the package (access to these methods and fields unless you specifically specify private , public or protected ) if the class that requests this access comes from the same classloader that loads the class he wants to access.

So, suppose the user calls his class java.lang.MyClass . Theoretically, he could access the packages for all fields and methods in the java.lang and change the way they work. Language itself does not interfere with this. But the JVM blocks this because all real java.lang classes have been loaded by the bootstrap boot loader. Not the same bootloader = no access.

Cool bootloaders have other security features built in that make it difficult to perform certain types of hacking.

So why three classes of loaders? Because they represent three levels of trust. The most trusted classes are core API classes. Next, extensions are installed, and then the classes that appear on the class path, which means that they are local to your machine.

See Bill Venners Inside the Java Virtual Machine for a more detailed explanation.

Answer 2

The main use of class loaders is the application server.

You want to run Tomcat (for example). This already requires at least one class loader to run tomcat.

Then you want to be able to deploy the application to Tomcat. Therefore, Tomcat itself must load the analysis of application classes, which was not even when Tomcat was launched.

Then you want to be able to deploy another application to Tomcat. Perhaps this second application uses the library that the first uses, but in a different version. Therefore, you want each application to have its own isolated class loader, otherwise the classes of application 2 could interfere with the classes from application 1 badly.

Then you want to be able to deploy one of the web applications. Therefore, its classloader must be destroyed and garbage collected to avoid a huge memory leak.

There are, of course, many other customs, but one that is most often used (in my experience).

Answer 3

• Several class loaders are present to load several applications at the same time (one for loading the server and another for deployment on the server).
• Each loader has a hierarchy for loading only certain classes to ensure security among them.