> 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