In general, there are two types of class loader: bootstrap class loader and user defined class loader.Įvery Java virtual machine implementation must have a bootstrap class loader, capable of loading trusted classes, and an extension class loader or application class loader.
Initialization: invokes Java code that initializes class variables to their proper starting values. Resolution: transforms symbolic references from the type into direct references. Preparation: allocates memory for class variables and initializing the memory to default values. Verification: ensures the correctness of the imported type. Linking: performs verification, preparation, and (optionally) resolution. Loading: finds and imports the binary data for a type. The class loader performs three basic activities in this strict order: Any implementation is free to recognize other binary forms besides class files, but it must recognize class files. A class loader implementation must be able to recognize and load anything that conforms to the Java class file format. One of the organizational units of JVM byte code is a class. Oracle owns the Java trademark and may allow its use to certify implementation suites as fully compatible with Oracle's specification. Clean-room Java implementations include Kaffe, OpenJ9 and Skelmir's CEE-J. One of Oracle's JVMs is named HotSpot, the other, inherited from BEA Systems is JRockit. Oracle provides tests that verify the proper operation of implementations of the Java Virtual Machine. We intend that this specification should sufficiently document the Java Virtual Machine to make possible compatible clean-room implementations. The specification for the JVM was published as the blue book, The preface states: As of 2006, changes to specification to support changes proposed to the class file format (JSR 202) are being done as a maintenance release of JSR 924. 
Starting with Java Platform, Standard Edition (J2SE) 5.0, changes to the JVM specification have been developed under the Java Community Process as JSR 924. Any Java application can be run only inside some concrete implementation of the abstract specification of the Java virtual machine. The main reason for this omission is to not unnecessarily constrain implementers. The garbage-collection algorithm used and any internal optimization of the Java virtual machine instructions (their translation into machine code) are not specified. It is a part of java runtime environment. The Java virtual machine is an abstract (virtual) computer defined by a specification.
1.6 Bytecode interpreter and just-in-time compiler.
0 kommentar(er)
