ClassLoading

Binary Class

• The binary class format is defined in the JVM spec. So compatible class files can be produced from any language definition.
• Every binary class starts with the "cafe babe" signature.
• Class format version numbers - minor and major.
• Bytecode is machine code for the JVM.
• The JVM uses a stack architecture with instruction operands being loaded onto an internal stack.
• Early JVM's were interpreters - Next gen JVM's added JIT to compile bytecode to native code.

Loading the classes

• C/C++ require a linker to merge all compiled code from various source files, alongwith code from libraries to form a single executable.
• In case of Java, it's different. Linking compiled classes is performed by the JVM when it loads the classes into memory.
• E.g. Apps can be written to use interfaces with the actual implementation loaded at runtime.
• Basic principle is that classes are loaded when needed.
• A lot happens inside the JVM when a class is loaded and initialized :
  • decoding the binary class format
  • checking compatibility with other classes
  • verifying the sequence of bytecode operations
  • finally constructing a java.lang.Class instance to represent the new class

Class Loaders

• Class loaders control class loading in a JVM.
• The bootstrap class loader is resp. for loading the basic Java library classes. Loads classes found on the boot class path. Since this is trusted, skips the validation process.
• Extension class loader for Java extension APIs.
• System class loader for classes from the general class path.
• Apps can also provide custom class loaders.
• Each class loader keeps a reference to custom class loaders.
• Example: Each J2EE application loaded by the framework needs to have a separate class loader to prevent classes in one application from interfering with other applications.