Dynamic Java programming

Dynamic Java programming
Part 1 loading of classes and Classes

Let's take a look at the classes and what they did when they were loaded by JVM?

In this new series of articles about dynamic Java programming features, we will see what happened behind the running Java application. Enterprise-level Java expert Dennis Sosnoski provides the Java binary format and Issues in the JVM internal classes. Follow this route, he introduced the scope of the impact of the classes being loaded (from the large number of classes required by a simple Java application that is running to the class loader in J2EE and similar complex framework structures problems that may result from a conflict ).

This article reveals a series of new knowledge contained in the topic of Java Dynamic Programming. These topics include the structure of the Java binary class file format, the use of reflection to access runtime metadata, and all the methods for editing and constructing new classes at runtime. The entire basic path of this material is the Java platform's programming philosophy, which is more dynamic than using other languages that directly compile the code at cost. If you understand these dynamic features, you can use Java to do things that cannot be done with other mainstream programming languages.

In this article. I introduced some basic concepts under the dynamic features of the Java platform. These concepts are used to describe the binary format of Java classes, including what happens when classes are loaded into JVM (Java Virtual Machine. This document not only provides the basis for understanding other articles on this series of topics, but also demonstrates the concerns of developers who actually work on the Java platform.

Binary form of a class
Developers using the Java language usually do not have to worry about the details that occur when running their source code through the compiler. In this series of topics. I will introduce many details behind the process from source code to executable programs. So let's take a look at the binary classes produced by the compiler.

The binary format is actually defined by the JVM (Java Virtual Machine) specification. A normal class description is generated by a compiler using the source code of the Java language and is usually stored in a file with the. class extension. However, none of these features are essential. Some other programming languages have been developed to use the Java binary class format, the description of the new class is created and directly loaded into an ongoing JVM. But what JVM cares about is not the source code or how it is stored, but the format itself.

So what does the format look like first? The following (List 1.) lists the source code of a very short class, followed by a part of the hexadecimal display of this class file output by the compiler:
List 1. source code and (partial) binary representation of Hello. java
Public class Hello
{
Public static void main (String [] args ){
System. out. println ("Hello, World! ");
}
}

0000: cafe babe 0000 002e 001a 0a00 0600 0c09 ................
0010: 000d 000e 0800 0f0a 0010 0011 0700 1207 ................
0020: 0013 0100 063c 696e 6974 3e01 0003 2829 ...... <init> ...()
0030: 5601 0004 436f 6465 0100 046d 6169 6e01 V... Code... main.
0040: 0016 285b 4c6a 6176 612f 6c61 6e67 2f53 .. ([Ljava/lang/S
0050: 7472 696e 673b 2956 0c00 0700 0807 0014 tring;) V ........
0060: 0c00 1500 1601 000d 4865 6c6c 6f2c 2057 ...... Hello, W
0070: 6f72 6c64 2107 0017 0c00 1800 1901 0005 orld !...........
0080: 4865 6c6c 6f01 0010 6a61 7661 2f6c 616e Hello... java/lan
0090: 672f 4f62 6a65 6374 0100 106a 6176 612f g/Object... java/
00a0: 6c61 6e67 2f53 7973 7465 6d01 0003 6f75 lang/System... ou
...

Binary internal
The first thing that represents the binary class shown in List1 is to identify the "caf babe" signature in the format of the Java binary class, this signature is just a simple method for verifying the data block of an instance in the Java class format of the actual request. Each Java binary class must start with these four bytes even on different file systems.
The rest of the data is not very interesting. The signature is followed by a version number in the class format (in this example, when the version is compiled using 1.4.1javac, the number of entries in the constant pool is 0, the base version is 46, and The hexadecimal format is 0x2e. The actual constant pool data follows the entry count (26 in this example, or 0x001a. This is the place to save the constants used by all class definitions. It includes the class and method names, signatures, and strings (these strings are Textual Interpretations of the correctness of the hexadecimal storage space that you can recognize), and various binary values together.
The project in the constant pool is variable-length. The first byte of each project identifies the project type and how it should be decoded. I am not going to detail this content. If you are interested in starting with the actual JVM specification, there are many useful references here. The key point is that the constant pool contains all references to other classes and methods used by this class, as well as the actual definitions of this class and its methods. Although the average value may be smaller, the size of the constant pool can easily be more than half or more of the binary class.

Following the constant pool, there are several projects that reference the constant pool entries. They are classes, their superclasses, and interfaces. These items are followed by information about fields and methods, which are described as a composite structure. The executable code of a method is included in the method definition in the form of code attributes (code attributes. This type of code is the JVM instruction form, usually called bytecode, which is one of the topics in the next section.

In Java class format, Attributes are used as several definitions, including the mentioned bytecode, the constant value of a field, exception handling, and debugging information. However, Attributes are not only used for these purposes. From the very beginning, the JVM specification requires JVMs (Java Virtual Machine) to ignore unknown attributes. This requirement provides flexibility for the use of attributes so that they can serve other purposes in the future, for example, provide the metadata required by the Framework Working with the user class ------ this is a Java method widely used in C # language. Unfortunately, no hook have yet been provided for making of this flexibility at the user level.

Bytecode and stack
The executable part of a file is the actual machine code adapted to a specific type of computer (JVM). This is called a virtual machine because it is designed and implemented by software rather than hardware. Every application running on the JVM is built on this machine.

Virtual machines are actually quite simple. They use the stack structure, which means that they will be loaded into an internal stack before being used. The instruction set includes all General Arithmetic Operations and logical operations, as well as conditional and untransferred operations, loading/storage, call/return, stack maintenance, and several special instruction types. Some commands including the immediate number are directly encoded into the command, and others are directly referenced from the constant pool.

Although the virtual machine is simple, the execution is not like this. The first generation of JVM is basically the virtual machine's bytecode parser, which is relatively simple, but it encountered a serious performance problem-parsing code always takes longer than executing local code. To reduce these performance problems, the second-generation JVM has added instant (JIT) translation. JIT technology is to compile the code at cost before the first execution of Java bytecode, so as to provide better performance for repeated execution. The current JVM is doing better. It uses corresponding technologies to monitor program execution and selectively optimizes code usage.

Loading class
After compiling the source code, the language (such as C and C ++) usually needs to be linked to this step after the source code is compiled. This link process combines independently compiled source files with the code of the shared class library to form an executable program. The Java language is different. The class files generated by the compiler are generally stored separately until they are loaded into a JVM, even creating a JAR file won't change this situation-the JAR file is only a container of the class file.

It is better than a separate step. When the JVM loads classes into the memory, the linked classes become part of the work that the JVM wants to perform. In this way, some system overhead can be added during initialization loading, but it also provides advanced flexibility for Java applications. For example, an application can be written using an actually implemented interface that is not known at runtime. This late binding method is widely used to assemble an application on the Java platform. servlets is a common example.

The rules for loading classes are clearly described in the details of JVM specifications. The basic principle is that classes are loaded only when needed (or at least display loading). This JVM method has some flexibility in the actual loading process, but a fixed class initialization sequence must be maintained ). Each loaded class can have other classes it depends on, so the loading process is recursive. The class in Listing 2 shows how this recursive load works. This Demo class contains a simple main method for creating an instance of the Greeter class and calling the greet method of this class. The Greeter class constructor creates a Message instance and uses this Message instance in the greet method.

Listing 2 source code for class loading demonstration
Public class Demo
{
Public static void main (String [] args ){
System. out. println ("** beginning execution **");
Greeter greeter = new Greeter ();
System. out. println ("** created Greeter **");