next up previous
Next: SecurityManager Up: The Libraries Previous: The Libraries

ClassLoader

The Java runtime has two distinct ways of loading a new class. The default mechanism is to load a class from a file on the local host machine. This mechanism does not need a ClassLoader. Any other way of loading a class, such as over the network, requires an associated ClassLoader (i.e. a subtype of the ClassLoader class which has some specialized methods). The ClassLoader is responsible for converting the raw data of a class (e.g. bytes transmitted over the network) into an internal data structure representing that class.

In order to have Java Applets be as portable as possible, the Java compiler does not compile to machine code, instead it compiles to bytecodes for a virtual machine. The Java interpreter runs a program by interpreting these bytecodes. Thus, Applets are transmitted in bytecode form instead of source code or machine code. This means that the ClassLoader only deals with bytecode.

For security reasons, the ClassLoader cannot make any assumptions about the bytecode. The bytecode could have been created by a Java program compiled with the Java compiler, or it could have been created by a C++ program compiled with a special compiler for the virtual machine.gif This situation means that the ClassLoader must verify that the bytecode does not violate the safety that Java guarantees. Aside from simple format checks, the bytecode verifier checks:

Along with checking the validity of the bytecode, the ClassLoader has the responsibility of creating a namespace for downloaded code, and resolving the names of classes referenced by the downloaded code.



next up previous
Next: SecurityManager Up: The Libraries Previous: The Libraries




Thu Dec 7 18:26:21 EST 1995