Classworking Toolbox: ASM classworking

Does the ASM classworking library claim to be small and fast? Just use the ASM 2.0 test to know.

Introduction: In this issue of the Classworking Toolbox, consultant Dennis Sosnoski the ASM bytecode operation framework with the bytecode Engineering library that he discussed previously in the Java Programming Dynamics series (byte Code Engineering Library, BCEL) and the Javassist framework for comparison. ASM claims to be small and fast-but what about comparing it to other frameworks? Dennis will evaluate the availability and performance of ASM using the examples he used in previous series articles.

A number of Java libraries have been developed that process bytecode and class files, including the Javassist and BCEL libraries I described in the previous Java Programming Dynamics series. The ASM is another updated library of this type. Unlike other libraries, ASM is designed and implemented to be as small and fast as possible. In this month's installment, I'll delve into how ASM is doing this, comparing it to the other two libraries used as examples in this series.

In the previous installment, I showed how to use run-time bytecode generation instead of reflection. I used the 1.4.1 JVM to test it and found that the generated code might run faster than the reflection code it replaced. In addition to using the same tools to test on ASM, I also updated the results in this installment, testing with 1.5.0 JVMs to see if the performance enhancements implemented in 1.5.0 would change the results.

Instead of reflection

The purpose of the sample application is to replace reflection with code generated at run time. In my dynamic series of Java programming, I've covered this topic in depth. In this installment, I'll make a quick background summary of the previous materials and see how the performance and availability of ASM compare with ASM instead of the Javassist and BCEL frameworks.

Setup phase

Reflection provides a very powerful mechanism for accessing objects and metadata at run time (as I discussed in "Java Programming Dynamics, Part 2nd"). Using reflection makes building applications more flexible, with external information to hook up each fragment at run time to form a working configuration. But using reflection to actually access an object is usually much slower than performing the same operation directly. Using a reflection based approach to building an application, and then discovering that performance needs to be improved, poses a real problem because the flexibility of reflection support is difficult to do otherwise.

Classworking technology provides a method. It does not use reflection to access the properties of an object, for example, you can build a class at run time to do the same thing-but it is much faster. "Java Programming Dynamics, part 8th" Demonstrates how to implement this type of reflection substitution with the two classworking frameworks Javassist and BCEL. The basic principles used in this article are simple: first create an interface that defines the required functions, and then build a class at run time (the class implements the previous interface and hooks the function to the target object).

Listing 1 illustrates this approach. Here, the Holderbean class contains a pair of properties that can be accessed at run time by invoking the get and set methods using reflection. The Iaccess interface abstracts the concept of accessing the Int Value property through the get and set methods, whereas the AccessValue1 class gives the implementation of this interface specifically for the "value1" property of the Holderbean class.

Listing 1. Reflection Substitution interface and implementation

public class Holderbean
{
private int m_value1;
private int m_value2; 　　

Public int getValue1 ({
return m_value1;
　　
public void setValue1 (int value) {
M_value1 = value;
　　

Public int getValue2 () {
return m_value2
　　
public void setValue2 (int value) {
M_value2 = value;
　　
}
Public interface iaccess
{
public void settarget (Object target);
public int getValue ();
public void SetValue (int value);
}
Public class AccessValue1 implements Iaccess
{
Private holderbean m_target;
　　
public void Settarget (Object target) {
M_target = (holderbean) target;
　　
public int GetValue () {
return m_target.getvalue1 ();
　　
public void SetValue (int value) {
M_target.setvalue1 (value);
}
}

If you have to manually encode each implementation class, such as the one in Listing 1, the entire method may not be very useful. AccessValue1 But the code in AccessValue1 is very simple, which makes it an ideal target for Run-time class generation. You can use AccessValue1 bytecode as a template to generate classes that are specific to target object types and Get/set method pairs, as long as they replace those targets used in AccessValue1. This is the method I used in previous articles and the ASM method I use in this issue.