This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Building Blockchain Apps and have Michael Yuan on-line!
See this thread for details.
Win a copy of Building Blockchain Apps this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Liutauras Vilda
  • Knute Snortum
  • Bear Bibeault
Sheriffs:
  • Devaka Cooray
  • Jeanne Boyarsky
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • salvin francis
Bartenders:
  • Tim Holloway
  • Piet Souris
  • Frits Walraven

why different class loaders?

 
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

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?

Please list other points if you have in mind...

Thanks
Maulin
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Very nice, Jim. Thanks!

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?
 
Jim Hicks
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes Stan it does make sense. Basicly the code:

Class.forName("string").newInstance()

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.
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jim

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 ..

Regards,
Maulin
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jim,

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
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow, Jim, that was way too clear for me to see on my own. Thanks!
 
Surfs up space ponies, I'm making gravy without this lumpy, tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!