An AOP tool: ASM 3.0 Introduction

With the development of AOP (Aspect oriented programming), code dynamic generation has become an integral part of the Java world. This article will introduce a compact and lightweight Java bytecode control framework ASM that can easily generate and transform Java code. The well-known frameworks, such as Hibernate and Spring, use ASM at the bottom. Compared to the traditional Java bytecode control framework, BCEL or SERP, it has a more compliant programming model and faster performance than the modern software model.

Introduction

What is ASM?

ASM is a Java byte-code manipulation framework. It can be used to dynamically generate classes or to enhance the functionality of existing classes. ASM can directly produce binary class files, or it can dynamically change class behavior before the class is loaded into the Java virtual machine. Java class is stored in a strictly formatted. class file that has enough metadata to parse all the elements in the class: Class name, method, property, and Java bytecode (instruction). After reading the information from the class file, ASM can change the class behavior, analyze the class information, and even generate the new class according to the user's request.

Unlike BCEL and Serl, ASM provides a more modern programming model. For ASM, Java class is described as a tree; use "Visitor" mode to traverse the entire binary structure; event-driven processing allows the user to focus only on the parts of the programming that are meaningful to them, without having to understand all the details of the Java class file format: The ASM framework provides the default " Response taker "deal with all this."

Why do you want to dynamically generate Java classes?

The dynamic generation of Java classes is closely related to AOP. The original purpose of AOP is that there is such a code in the world of software design that is fragmented and coupled: fragmented because some public functions (such as the famous log example) are scattered across all modules, and changing the log function affects all modules. This flaw is largely due to the fact that traditional object-oriented programming focuses on the "vertical" relationship represented by inheritance, while the "horizontal" relationship between modules that have the same function or aspect (Aspect) is not well expressed. For example, there is currently an existing banking management system, including bank, Customer, account, Invoice and other objects, now to join a security screening module, the existing classes must be a security check before all operations.

Figure 1. Asm–aop

However, Bank, Customer, account, Invoice are representing different transactions, derived from different parent classes, it is difficult to add to the top of the security Checker common functions. This is especially true for Java, where there is not much inheritance. The traditional solution is to use the decorator mode, which can improve coupling to some extent, while the function is still dispersed--every class that needs security Checker must derive a decorator, each method that requires security Checker is packaged (wrap). Let's take the account class for an example to look at decorator:

First, we have a Securitychecker class whose static methods checksecurity perform security check functions:

public　class　SecurityChecker　{
　public　static　void　checkSecurity()　{
　System.out.println("SecurityChecker.checkSecurity　...");
　//TODO　real　security　check　
　}
}

The other is the account class:

public　class　Account　{
　public　void　operation()　{
　System.out.println("operation...");
　//TODO　real　operation　
　}
}