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.
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.