Spring Core source code interpretation one of the ASM4 User manual translations ASM Introduction

1.1 ASM Motive:

Program analysis, generation, and conversion techniques can be applied to many scenarios:

1. Program analysis, from simple syntax parsing to complete semantic analysis, can be applied to find potential bugs in the program, find useless code, reverse engineering code, and so on.

2. Code generation is applied in a variety of compilers: both traditional compilers and distributed programming stubs or skeleton compilers, instant compilers, and so on.

3. Code conversion, can be used to optimize or confuse the program, insert test or Performance Monitor to the application, aspect-oriented programming and so on.

These techniques can be used in any programming language, but more or less easily depending on the language. In the Java language, they can be applied in the source code or in the compiled class file. One of the benefits of using the compiled class file is: Obviously, no source code is required. Code transformations can be applied to any application, including source-closed applications and commercial applications. Another application to the compiled code is that it can parse, generate, and transform classes at run time (that is, before classes are loaded into Java virtual machines). Java virtual machines are used to generate and compile source code during runtime, but it is slower and requires a complete Java compiler. The advantage is that for the user, such tools such as stub compilers or facet weavers are transparent.

Because of the many uses of program analysis, generation and conversion techniques, many languages contain Java's tools for analysis, generation, and transformation. ASM is a tool designed for the Java language to generate and transform classes that are run-time (not offline). So the ASM Library is designed for compiled Java class files. It is designed to run as fast as possible, taking up less space. As fast as possible without affecting the speed at which ASM applications are used at run time, as small as possible in order to avoid the use of ASM for small applications or space expansion of libraries due to the environment in which memory resources are severely constrained.

ASM is not just a tool for generating and converting compiled Java classes, it is also one of the most modern and efficient tools. Can be downloaded from http://asm.objectweb.org to ASM. The main features of ASM are the following:

1. It has an easy-to-use, perfectly designed, modular API.

2. It is well documented and has a plug-in associated with Eclipse.

3. It provides support for Java 7, the latest version of Java.

4. Small size, fast speed, good robustness.

5. Provide huge community support for new users.

6. Open source, allow you to use any.

1.2 ASM Overview:

1. Domain

The goal of the ASM Library is to generate, transform, and parse compiled Java classes (represented as byte arrays, as they are stored on disk and then loaded into a Java virtual machine). Because of this goal, ASM provides tools for reading and writing these byte arrays using a higher level of abstraction than bytes, such as numeric constants, strings, Java identifiers, Java types, Java class structure elements, and so on. Note: The fields of the ASM library are strictly limited to read, write, transform, and parse classes. In particular, the class is loaded more than this domain.

2. Model

The ASM Library provides two types of APIs to generate, transforming compiled classes: The Core API provides an event-based class representation, and the tree API provides an object-based presentation.

In an event-based model, a class behaves as an event sequence, each representing an element of the class, such as a header, field, method declaration, an instruction, and so on. The event-based API defines a set of possible events and the order in which it must occur, and provides a class parser: it produces an event based on each element it parses; a writer: produces a compiled class from the sequence of events.

In an object-based model, a class is represented as an object tree, and each object code is part of a class, for example: The class itself, a field, a method, an instruction, and so on. Each object has an object reference that represents it. The object-based API provides a way to convert the sequence of events representing a class into an object tree representing the same class, and vice versa, converting an object tree to an equivalent sequence of events. In other words, object-based APIs are built on event-based APIs. The comparison of the two APIs can be described as: Sax (XML Simple API) and DOM (Document Object model), where event-based APIs resemble sax, and object-based APIs resemble Dom. Object-based APIs are built on event-based APIs, just as Dom is built on sax.

ASM provides both APIs because none of the APIs is better than the other API. In fact, each API has its own pros and cons:

1. Event-based APIs are faster and require less space than object-based APIs. Because there is no need to create and store an object tree in memory that represents a class (the same is true between Sax and DOM).

2. Event-based APIs are more difficult to implement class conversions because only one element of the class (the element that corresponds to the current time) can be accessed at any time, and object-based APIs are accessible in memory.

Note: Both APIs can manage only one class in one event and are independent of each. The inheritance information of a class is not saved, and if the transformation of a class affects other classes, the class must be modified by the user.

3. Architecture:

ASM applications have a strong architectural view. In fact, event-based APIs are organized around event generators (class parsers), event consumers (class writers), and various predefined filters, and user-defined producers, consumers, and various filters can be easily added. Thus, using this API requires two steps:

1, the event's producers, filters, consumer components compiled into a complex architecture.

2. Then run the event producer to run the production or conversion process.

An object-based API also has a Schema View: The class generator and converter components that manipulate the object tree, and the connection between them represents the order of conversions.

Although most component architectures, especially ASM applications, are very simple, they can be associated with complex architectures such as the following:

Arrows represent event-based or object-based connections between class parsers, writers, and converters, and events or object-based transformations exist everywhere in the chain structure.

1.3 Organizational Structure:

The ASM library consists of several different packages, which are placed into different jar files:

Package Org.objectweb.asm and Org.objectweb.asm.signature define event-based APIs and provide class parsers and writer components that are penetrated into the Asm.jar file.

Package Org.objectweb.asm.util, which was scored into the Asm-util.jar file, provides a number of core API-based tools that can be used in the development and debugging of ASM applications.

Package Org.objectweb.asm.commons provides some useful pre-defined class converters, mostly based on core APIs. It is packaged in Asm-commons.jar.

Package Org.objectweb.asm.tree, packaged into a Asm-tree.jar file, defines an object-based API that provides an event-based and object-based representation of the transformation tool.

Package Org.objectweb.asm.tree.analysis provides a class analysis framework based on the tree API and some class parsers that are packaged into Asm-analysis.jar files.

The document contains two sections, the first part describes the core APIs, such as: Asm,asm-util and asm-commons files. The second section describes the tree APIs, such as: Asm-tree and asm-analysis files. Each section has at least one chapter that describes the API for the Association class, the API for the associated method, and the API for associating annotations, generic types, and so on. Each chapter contains programming interfaces and related tools and predefined components. All instances of source code can be downloaded from the ASM official website.

This form of organization makes it easier to progressively introduce the various characteristics of a class file, but sometimes it is necessary to extend the representation of a single ASM class in some chapters. Therefore, it is recommended that the documents be read in the order they are arranged. If you use only the ASM API for this manual document, use the Javadoc

Typographic conventions

< > Acknowledgements

Thanks François Horn. During the compilation of this document, his valuable comments greatly improved the structure and readability of the document.

Core API, TREE API follow-up ....

• This article is from: Linux Learning Tutorial Network

Spring Core source code interpretation one of the ASM4 User manual translations ASM Introduction