Difference between revisions of "ClassLoading"
From Suhrid.net Wiki
Jump to navigationJump to search| Line 14: | Line 14: | ||
* E.g. Apps can be written to use interfaces with the actual implementation loaded at runtime. | * 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. | * 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 | ||
Revision as of 11:05, 23 November 2012
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
