• Post Reply Bookmark Topic Watch Topic
  • New Topic

system level classpath, application level classpath, classloader  RSS feed

 
srinivasrao marri
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i have a lot of jar files, what i am doing is ,
java -classpath <giving all my jar file names>

the question is , this class path is setting at application level or system level? and how the class loader is taking these things?

is it a feasible idea , to write our own classloader where only my set of jar files will be loaded for that particular application?, so that the performance of os will be improved,

the user level and system level environment variables can be observed in windows operating systems.

Pls clarify me in this regard

Thank you
Srinivas
 
john guthrie
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if i understand you correctly, the classpath as specified via "java -classpath ..." is an application-level classpath. running another java program in another jvm would not pick up that classpath automatically.
an environment variable %CLASSPATH% (windows, of course) could be thought of as system-wide.
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

an environment variable %CLASSPATH% (windows, of course) could be thought of as system-wide.

That's only true in DOS kernel Windows(9X). For NT based machines (NT, 2K and XP) there are two sets of environment vars, System and User.
 
srinivasrao marri
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now a days ever application/web server provider is giving us the class loaders, like ejb class loader and web classloader. why they are providing these class loaders? what are the advantages i get by using them?
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Two important reasons, I think.
  • To dynamically determine the location from which classes are loaded. When you deploy a web-application called "foobar", the server needs to suddenly be able to load classes from "/deployments/foobar/WEB-INF/classes" and every jar in "/deployments/foobar/WEB-INF/lib". There's no way you can do that by setting up a static CLASSPATH.
  • To isolate different applications. EJBs and web-applications often use classes of the same name -- different versions of supporting libraries, or coincidental nameclashes -- and each needs to get their copy from "their" classes and jars. The only way to do this is to give them all their own classloaders.
  • - Peter
     
    Consider Paul's rocket mass heater.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!