I am trying to think more conceretly about reasons of having different class loaders like Appclass loader, Extension class loader etc...
Please help me list out the reasons. Here I have one listed,
1. To allow extensibility as applet has its own class loader , RMI's stub download thing can be having its own class loader that loads classes from socket connection etc
2. I am not sure how these different class loaders help in security? Let me write what I think-- I believe that Applet classloader uses a policy file and forces that only explicitly allowed code is able to do certain things where as the Appclass loader might just allow any class to write files and all you know ...So I guess as "different classloaders can use different enforcement mechanisms on classes loaded by itself" makes it applicable to security aspect , right?
Every classloader has a classpath. Every classloader, except the primordial classloader has a parent. When a classloader is asked to load a class, it always ask its parent classloader to load it. Only if the parent can not find the class will it load the class.
The load order of the parent always going first, prevents an application from trying to change the function of a class with the same name, like java.security.AccessController. If an application's class loader went first, it could override the security.
The JVM has an extension class loader that loads classes from the ext lib when the jvm starts. Jars placed in the extension lib will always be there. They will be like java.lang always in the jvm.
In a JVM, you may have multiple apps executing at the same time. Each app will be loaded by its own class loader because each app needs it own class path.
If you placed mycode-1.0.jar in the ext lib all apps would use mycode-1.0.jar because it was loaded by a parent classloader. Placing mycode-2.0.jar into your application's classpath would not change this. So all applications in a jvm must use the same version of any jars placed in the extension lib.
In our shop, each app has its own area that contains its own jars but these application jars usually only deal with presentation. We place the business rules in a common repository. Business rules are reused in many applications. Example: a parts order can come in from 5 different ways at our company. Via web pages, ftp, web servcies etc. You do not want to write a version of parts order proessing for each application. The application only knows that it needs to execute a particular business rule.
The business rule has dependencies, like daos. A property file in the repository that holds the business rules, tells us what dependencies a business rule has. We use this to create instances of URLClassloader. The jars in the dependency list are added to the classpath of this classloader. We use the URLClassloader to get an instance of the business rule.
So maybe you know ... in an EJB app, we get class names from configuration and create instances. Regular class.forName("string").newInstance() fails with class not found. If we use the loader that loaded the factory - getClass().getClassLoader() - in the forName call things work. Does that make sense?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jun 23, 2004
Yes Stan it does make sense. Basicly the code:
is asking the class named "Class" to load a class.
The class named Class is loaded by the system classloader. So when you ask Class to load a class it ask the system classloader to load the class. If you do that, then only the classpath settings for the system classloader and its parents will be searched.
When you are in an EJB you are several classloasders below the system. There is at least one for the container and usually more. In order to locate a class set in the container's classpath or lower, you must use something other than the system classloader.
Joined: Nov 04, 2001
I understand how class loading works. Aparently from your post it seems you explained how class loading works but that is not my question.
My question is "why different class loaders?". I guess my question is more pointing towards design...
I would read your post again carefully to see I didn't miss anything answering my question ..
Joined: Nov 04, 2001
Sorry for missing couple of important statements from your post that goes into answering my question...
-------- class with the same name, like java.security.AccessController. If an application's class loader went first, it could override the security. ------------ But can we write a package name java.security? Last time I worked on it, it didn't allow me package name with java or javax etc you know ...I'll test it again and see what I get. Can you please explain me how this is possible if you are aware of doing that by yourself?
------ We use this to create instances of URLClassloader. The jars in the dependency list are added to the classpath of this classloader. ------ This makes senese to me. You are having custom class loading. So this goes with my first comments in the first post.
Thanks for your input. Maulin
Joined: Jan 29, 2003
Wow, Jim, that was way too clear for me to see on my own. Thanks!