Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2005

Tip: Looking for answers? Try searching our database.

What' happening behind scene in Hello World?

Thread view: 
Ueland - 01 Nov 2005 20:36 GMT
I'm looking at the HelloWorld program

class HelloWorld {
  public static void main(String args[]) {
     System.out.println("Hello World");
  }
}

When I compile the program above and run it using
>java HelloWorld

the first thing java (I'm writing java because I do not know who does
this thing) does is to initialize a lot of things and then it runs the
main() method above. One of the things that happens behind the scene is
that it imports java.lang and that it creates a PrintStream object in
the Heap and lets the static variable System.out point to it.

I would like to understand how this initialization works. Looking at
the System.java in the package java.lang I find the following code

   /**
    * Initialize the system class.  Called after thread
initialization.
    */
   private static void initializeSystemClass() {...

My question is what is calling the thread initialization and what is
calling initializeSystemClass(). In other words how does the
initialization of the environment (in which my program HelloWorld will
execute) begin in the first place. Also what tool or software component
is responsible making all these initializations?

Bob Ueland
Ross Bamford - 01 Nov 2005 21:42 GMT
> I'm looking at the HelloWorld program
>
[quoted text clipped - 9 lines]
> the first thing java (I'm writing java because I do not know who does
> this thing)

With the Sun platform, Lots of different bits are involved, including a  
'java' executable wrapper, shared libraries, and Java code...

 does is to initialize a lot of things and then it runs the
> main() method above. One of the things that happens behind the scene is
> that it imports java.lang and that it creates a PrintStream object in
> the Heap and lets the static variable System.out point to it.

Firstly, 'importing' java.lang is a notion applicable only to the compiler  
- class files don't import things - they're statically linked to other  
class files by the compiler. For it to find them and link to them, you  
must use the 'import' directive in your source. I think you're referring  
to loading the system classes (see below).

Without going into the offtopic details (in other words, _very_ simply)  
when you fire up 'java' (a fairly simple wrapper) it loads and initializes  
the appropriate shared libraries (libjvm.so and many more) for the JVM you  
specify (client or server). This then handles it's own initialization,  
such as allocating the various heaps, setting up signals, and so on. Once  
that's done, it's ready to start running Java code, leading us to...

> I would like to understand how this initialization works. Looking at
> the System.java in the package java.lang I find the following code
[quoted text clipped - 10 lines]
> execute) begin in the first place. Also what tool or software component  
> is responsible making all these initializations?

Once the JVM is up, it creates the bootstrap classloader(*), following the  
normal classloading semantics as described in the spec. As each class is  
loaded it is resolved and linked, and has it's static initializer run (a  
combination of any static field initializers and static { ... } block).  
Most of what you and I would consider as 'initialization' goes on here, as  
the static initializers on classes such as System, Runtime, and so on grab  
information from the JVM (often using native methods implemented by the  
native shared libraries), load other classes, and perform all the other  
general setup like creating the System.in and System.out streams (which  
might be done indirectly initializeSystemClass). By now a number of  
threads will be running to support things within the VM, Swing, and so on.  
Try hitting CTRL-\\ in a console 'java' session and you'll get a list of  
them.

Once the platform has been loaded things move on to the regular classpath,  
with your main class being loaded and resolved and having it's initializer  
run, possibly causing further classloading and initialization activity to  
take place.

Once everthing is loaded and initialized, various tools get a look in,  
with things like the premain method on Java agents being run. Of course,  
any of this may cause a further round of classloading, both in and out of  
the platform, as your classes initializers, those of an agent, or any  
other class loaded by them reference yet more classes. As each one is  
loaded for the first time it gets the same treatment.

And finally, your main() method is called, passing in the command-line  
arguments supplied to the java command. Although control now transfers to  
your code, initialization isn't really over since there will most likely  
be further classloading, resolution and initialization as your application  
(and the libraries it uses) first uses them.

There's quite a bit of information about startup and initialization in the  
JVM spec, and the JLS talks about static initializers and the like (I  
can't remember exactly where though).

Signature

Ross Bamford - rosco@roscopeco.remove.co.uk



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.