aspose file tools*
The moose likes Java in General and the fly likes classloader Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "classloader" Watch "classloader" New topic
Author

classloader

sri jaisi
Greenhorn

Joined: Sep 02, 2006
Posts: 23
java myclass.java;

whatz actually happening when we run a class;i knew that main method is the entry point for execution and classloader is responsible for loading the class when it sees some line like new myclass();but my question is even to get to the main method the class has to be already loaded;

thankz
sri
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18715
    
  40

The main() method is the "entry point for execution" for your java program. The starting point for the JVM is something else. This starting point call code that parses the parameters, setups tons of internal stuff, loads and configure the class loader, load your class specified in the parameters (with the class loader), and then call your main() method.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

Heh...Who cops the cops is what you're asking...Who loads the first classloader?

I wrote a number of articles on classloaders. Here's a segment of one of them on the null classloader. I hope you enjoy. You can read the rest of the arcticle here if you please. It's a little WebSphere specific:

Everything You Want to Know About WebSphere and J2EE Classloaders


Java classes are loaded by classloaders, and classloaders are Java components, who loads the first classloader?

The old chicken and egg scenario, rearing its ugly head. If classloaders are Java classes, and Java classes must be loaded onto a JVM to run, how does the first classloader get loaded? It�s a good question.

When a JVM starts up, a special chunk of machine code runs that loads the system classloader. This special hunk of machine code is known as the null classloader.


The Null Classloader

The machine code that initializes the system classloader is referred to as the null classloader because it is not a Java class at all, as are all other classloaders. The null classloader is platform specific machine instructions that kick off the whole classloading process.

All classloaders, with the exception of the null classloader, are implemented as Java classes. Something must load the very first Java classloader to get the process started. Loading the first pure Java classloader is the job of the null classloader.

The null classloader also takes care of loading all of the code needed to support the basic Java Runtime Environment (JRE), including classes in the java.util and the java.lang packages.
The System Classloader: sun.misc.Launcher

The null classloader loads a true Java class of type sun.misc.Launcher. The sun.misc.Launcher classloader prepares the basic Java Runtime Environment needed by our application server.

Truth be told, the sun.misc.Launcher is actually made up of two inner classes that do the actual classloading:

F sun.misc.Launcher$ExtClassLoader (parent)
F sun.misc.Launcher$AppClassLoader (system)

ExtClassLoader is the parent of AppClassLoader. Of the two, the inner class, sun.misc.Launcher$AppClasLoader holds the true title of system classloader

Quite appropriately, the sun.misc.Launcher is often referred to as the bootstrap classloader as well as the system classloader. Any jars found in the jre/lib directory of the JRE (not the WebSphere lib directory), will be loaded by the system classloader. The system classloader is tightly integrated with the components that implement the Java Runtime Environment (JRE).

From within the WebSphere administrative console, you have the option of adding Java files and resources to the WebSphere CLASSPATH. When you add libraries to the WebSphere CLASSPATH, you are actually asking the system classloader to load those classes when they are needed. Appropriately, the system classloader is also known as the CLASSPATH classloader.
sri jaisi
Greenhorn

Joined: Sep 02, 2006
Posts: 23
thankz henry and thankz kameron

kameron i read your article and i still got some doubts and please can you explain them in little more detail
let me start again with a simple example:
java myclass.java;now null classloader instantiates system classloader (as classloaders are hierarchial and as they follow delegation module extension loader ,bootstrap loader will try to load myclass.class file when it come across the line new myclass());
am i correct here?(or else bootstrap loader loads java.* classes and extension loader loads javax.*,and system class loader is the one responsible to load user defined classes in my case i.e.myclass.class)

2.if iam having one public class and two are more non public classes within the same file and if iam instantiating them means eg;new a();new b();new c();then wil three insances of system class loader will be created and each instance will try to find the corresponding .class file;
am i correct here

thankz for reading
sri
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Note that much of what K/Cameron is saying is implementation-dependent and undocumented -- not stuff you need to know. The important points are that the JVM itself starts up, and a specific class loader is created for the purpose of loading application classes. The Java application launcher (i.e., java.exe) then uses this class loader, along with the class name you specify on the command line and the Class.forName() function, to load the class in which main() is expected to appear. main() is then invoked using reflection (or equivalent magic.)

There's just a single application class loader; Java won't create any more class loaders once it starts loading your application classes.


[Jess in Action][AskingGoodQuestions]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: classloader