Java Virtual machine schematic diagram--1.1, class file basic organizational structure [go]

As a Java program ape, we know that we have written well. Java source code, and finally compiled by the Java compiler to a. class file, which is a file consisting of bytes, also known as bytecode files. So what exactly is inside the class bytecode file? How is it organized? Let's take a look at the structure of his composition first.

NO1. Magic Number (Magic)

All of the first 8 bytes of the class file compiled by the Java compiler are "0xCAFEBABE"
What it does is that when the JVM tries to load a file into memory, it first determines if the class file has a "signature" that the JVM deems acceptable-that is, the JVM reads the first 8 bytes of the file, determines whether the 8 bytes are "0xCAFEBABE", and if so, The JVM will assume that this file can be loaded and used as a class file.

NO2. Version number (minor_version,major_version)

With the development of Java itself, Java language features and JVM virtual machines will be updated and enhanced accordingly. Currently we can use the JDK version such as: 1.5,1.6,1.7, and today's latest 1.8. The purpose of the new release is to add new features to the original version and optimize the corresponding JVM virtual machine. As with the minor version released by the major version, the bug that appears on the corresponding major version is modified. We usually just need to focus on the main version.

The major and minor version numbers each account for two bytes in the class file, and the secondary version numbers occupy the 5th, 62 bytes, while the major version numbers occupy the 7th and 82 bytes. The major version number of the JDK1.0 is 45, and each subsequent new major version will add 1 to the original version. If you are using JDK1.7 compiled class file, then the corresponding major version number should be 51, corresponding to 7, 8 bytes of hexadecimal value should be 0x33.

A JVM instance can only support a specific range of major version numbers (Mi to MJ) and 0 to a specific range (0 to M) of the sub-version number. Assuming that a class file has a format version number of V, this class file can be supported by this Java virtual machine only when MI.0≤V≤MJ.M is established. Different versions of the Java Virtual Machine Implementation support the version number is also different, the high version of the Java Virtual Machine implementation can support the lower version of the Class file, the reverse is not true.

When the JVM loads the class file, it reads out the major version number and then compares the major version number of the class file with the version number of the JVM itself, and if the JVM itself has the version number < class file version number, the JVM will think that the class file cannot be loaded. Throws the "Java.lang.UnsupportedClassVersionError:Bad version number in. class file" Exception that we often see, whereas the JVM thinks it can load this class Continue loading this class file.

Tips :

1. Sometimes we throw this exception when we run the program: "java.lang.UnsupportedClassVersionError:Bad version number in. class file". The reason for this problem is that the JVM virtual machine that is currently trying to load the class file is below the version of the class file. WORKAROUND: 1. Re-use the current JVM to compile the source code, and then run the code; 2. Update the current JVM virtual machine to the version of the class file.

2. How do I view the version number of a class file?

You can use the text Editing tool to directly view the file's 7, 8-byte value, determine what version of the class file.

Of course the quick way to use the JDK's own JAVAP tool, such as the current Programmer.class file, into the directory where the file is located, and then execute "javap-v Programmer", the results will resemble the following:

NO3. Constant Pool counter (constant_pool_count)

Chang is a very important structure in the class file that describes the literal information of the entire class file. Chang is made up of a set of constant_pool struct arrays, and the size of the array is specified by a constant pool counter. The value of the constant pool counter constant_pool_count the number of members in the =constant_pool table + 1. The index value of the Constant_pool table is considered valid only if it is greater than 0 and less than Constant_pool_count.

NO4. Constant pool data area (Constant_pool[contstant_pool_count-1])

Constant pool, constant_pool is a table structure that contains all the string constants, class or interface names, field names, and other constants referenced in the class file structure and its sub-structures. Each item in a constant pool has the same formatting characteristics-the first byte is used as a type tag to identify what type of constant the item is, called Tag byte. The index range for a constant pool is 1 to constant_pool_count−1. The specific details of the constant pool will be discussed later.

NO6. Access Flag (Access_flags)

An access flag, Access_flags, is a mask flag that represents the access rights and underlying properties of a class or interface.

NO7. Class Index (This_class)

Class index, the value of This_class must be a valid index value for the item in the Constant_pool table. The Constant_pool table at this index must be a Constant_class_info type constant, representing the class or interface defined by the class file.

NO8. Parent class Index (SUPER_CLASS)

The parent class index, for classes, the value of Super_class must be 0 or a valid index value for an item in the Constant_pool table. If its value is not 0, then the entry at this index of the Constant_pool table must be a Constant_class_info type constant, representing the immediate parent class of the class defined by the class file. The immediate parent class of the current class, and all of its indirect parent classes, cannot have acc_final tags in the access_flag. For an interface, the value of the Super_class entry for its class file must be a valid index value for the item in the Constant_pool table. The entry for the Constant_pool table at this index must be a Constant_class_info type constant representing the Java.lang.Object. If the Super_class value of the class file is 0, then the class file may only be defined as the Java.lang.Object class, except that it is the only class that does not have a parent class.

NO9. Interface Counters (interfaces_count)

Interface counter, the value of Interfaces_count represents the number of direct parent interfaces for the current class or interface.

NO10. Interface Information data area (Interfaces[interfaces_count])

The value of each member in the interface table, interfaces[] array must be a valid index value for the item in the Constant_pool table, and its length is interfaces_count. Each member Interfaces[i] must be a constant_class_info type constant, where 0≤i <interfaces_count. In the interfaces[] array, the interface order represented by the member is the same as the given interface order (from left to right) in the corresponding source code, i.e. Interfaces[0] corresponds to the leftmost interface in the source.

NO11. Field counter (fields_count)

Field counter, the value of Fields_count represents the number of members of the current Class file fields[] array. Fields[] Each item in the array is a data item of the FIELD_INFO structure that is used to represent the class or instance field of the class or interface declaration.

NO12. Field Information data area (Fields[fields_count])

Each member in the Field table, fields[] array must be a data item of the FIELDS_INFO structure that represents the complete description of a field in the current class or interface. The fields[] array describes all the fields declared by the current class or interface, but does not include the part that inherits from the parent or parent interface.

NO13. Method Counter (Methods_count)

The value of the Methods_count method counter, which represents the number of members of the current class file methods[] array. Methods[] Each item in an array is a data item of a METHOD_INFO structure.

NO14. Method information Data area (Methods[methods_count])

Each member of the method table, methods[] array must be a data item of the METHOD_INFO structure that represents the complete description of a method in the current class or interface. If the access_flags item of a METHOD_INFO structure is neither set acc_native flag nor set Acc_abstract flag, then its corresponding method body should be able to be loaded directly from the current class by the Java virtual machine without having to refer to other classes. The METHOD_INFO structure can represent all methods defined in classes and interfaces, including instance methods, class methods, instance initialization method methods, and class or interface initialization method methods. Methods[] Array only describes methods declared in the current class or interface, excluding methods inherited from parent or parent interfaces.

NO15. Property counters (Attributes_count)

The value of the Attributes_count property counter, which represents the number of members of the current Class file attributes table. Each item in the attributes table is a data item for a ATTRIBUTE_INFO structure.

NO16. Attribute Information data area (Attributes[attributes_count])

property sheet, the value of each item of the attributes table must be a attribute_info structure.

In the Java 7 specification, the entries for the attributes table in the class file structure include the following defined properties: Innerclasses, Enclosingmethod, synthetic, Signature, Sourcefile,source Debugextension, Deprecated, Runtimevisibleannotations, Runtimeinvisibleannotations, and Bootstrapmethods properties.

For Java virtual machine implementations that support the Class file format version number 49.0 or higher, you must correctly identify and read the signature in the Attributes table, Runtimevisibleannotations and Runtimeinvisibleannotations properties. For Java virtual machine implementations that support the class file format version number 51.0 or higher, the Bootstrapmethods attribute in the attributes table must be correctly recognized and read. The Java 7 specification requires that any Java Virtual machine implementation can automatically omit several (or even all) of its unrecognized property entries in the Attributes table of the Class file. Any attribute not defined in this specification cannot affect the semantics of the class file, but can provide additional descriptive information.

According to the above narrative, we can summarize the file organization structure of class to the following structure:

Bibliography:

Java Virtual Machine specification (Java SE 7) Chinese version (java_virtual_machine_specification_java_se_7)

[In-depth understanding of Java Virtual machines: JVM advanced features and best practices]. Zhou Zhiming

author's words

This article is the first of the Java Virtual machine schematic diagram, if you are interested, please follow the other articles in this series ~

Think this article is good, handy point a praise Oh ~ ~ Your encouragement, is I continue to share the powerful power of knowledge!

--------------------------------------------------------------------------------------------------------------- --------------------------

This article originates from http://blog.csdn.net/luanlouis/

Java Virtual machine schematic diagram--1.1, class file basic organizational structure [go]