org.springframework.asm is a bytecode processing package used internally by Spring Framework. It originates from ASM, with Spring repackaging ASM into its own namespace for directly reading, analyzing, and generating JVM .class files.

In Spring's source code, one extremely important use of ASM is:

Directly reading class, method, annotation, and other metadata from .class files without loading the Java class.

Understanding this package doesn't require researching all implementation classes from the start. Just establish this main line:

TEXT

Reading:
.class
  ↓
ClassReader
  ↓
ClassVisitor
  ├─ FieldVisitor
  ├─ MethodVisitor
  └─ AnnotationVisitor


Writing:
ClassVisitor / MethodVisitor
  ↓
ClassWriter
  ↓
byte[]
  ↓
.class

1. Why Spring Needs ASM

Assume a project contains:

JAVA

@Component
public class UserService {

    @Autowired
    private UserRepository repository;

    public User findById(Long id) {
        return repository.findById(id);
    }
}

During Spring's startup process when scanning the classpath, it needs to know:

TEXT

What is this class called?
Is it an interface?
Is it an abstract class?
What annotations does it have?
Does it have @Component?
What methods does it have?
What annotations do the methods have?

One approach is to use Java reflection:

JAVA

Class<?> clazz = Class.forName(
        "com.example.UserService"
);

Component component =
        clazz.getAnnotation(Component.class);

But this requires first having the JVM load the class.

When Spring scans the classpath, it may face tens of thousands of .class files. Many of these classes will never become Beans, so there's no need to load all candidate classes into the JVM just to read a small amount of metadata.

ASM provides another path:

TEXT

UserService.class
        ↓
Read binary Class File
        ↓
Parse class metadata
        ↓
Discover @Component

The entire process doesn't require first obtaining:

JAVA

Class<UserService>

Therefore, Spring can separate:

TEXT

Metadata reading

from:

TEXT

Java class loading

This is the most important point for understanding Spring ASM.

2. ASM Operates on Java Source Code? No - ASM Operates on JVM Class Files

ASM operates on JVM Class Files.

Java source code:

JAVA

public class UserService {

    public int add(int a, int b) {
        return a + b;
    }
}

After javac compilation:

TEXT

UserService.java
      ↓
    javac
      ↓
UserService.class

The .class file doesn't simply store Java source code; it's a binary structure defined by the JVM, roughly containing:

TEXT

ClassFile

├─ magic
├─ version
├─ constant_pool
├─ access_flags
├─ this_class
├─ super_class
├─ interfaces
├─ fields
├─ methods
└─ attributes

ASM works around these structures.

Therefore, you'll encounter many concepts in ASM that look different from Java programming habits:

TEXT

descriptor
internal name
constant pool
opcode
label
frame
attribute

These concepts actually come from JVM Class Files, not invented by ASM itself.

3. ASM's Core Design: Reader + Visitor + Writer

ASM's most core design can be summarized as:

TEXT

Reader
  ↓
Visitor
  ↓
Writer

Where:

TEXT

ClassReader

is responsible for reading .class.

TEXT

ClassVisitor
MethodVisitor
FieldVisitor
AnnotationVisitor

are responsible for visiting information at different levels within a class.

TEXT

ClassWriter
MethodWriter
FieldWriter
AnnotationWriter

are responsible for regenerating the class.

This API is very similar to SAX for parsing XML.

It typically doesn't require first converting the entire class into a huge object tree before processing. Instead, it continuously generates visit events during parsing:

TEXT

Start visiting class
    ↓
visit(...)

Discover annotation
    ↓
visitAnnotation(...)

Discover field
    ↓
visitField(...)

Discover method
    ↓
visitMethod(...)

Discover bytecode instruction
    ↓
visitInsn(...)

Visit ends
    ↓
visitEnd()

Therefore, ASM's core API is perfect for:

TEXT

Quick scanning
Bytecode analysis
Bytecode transformation
Java Agent
Framework metadata reading

4. ClassReader: Reading `.class`

ClassReader is the main entry point for reading with ASM.

For example:

JAVA

ClassReader reader =
        new ClassReader("com.example.UserService");

Then:

JAVA

reader.accept(visitor, 0);

The entire process can be understood as:

TEXT

ClassReader
    │
    │  Read class binary structure
    ↓
ClassVisitor.visit(...)
    ↓
ClassVisitor.visitAnnotation(...)
    ↓
ClassVisitor.visitField(...)
    ↓
ClassVisitor.visitMethod(...)
    ↓
ClassVisitor.visitEnd()

Note:

JAVA

reader.accept(...)

is not simply "handing data to the Visitor."

More accurately:

ClassReader parses the .class while actively calling the corresponding Visitor methods.

This is the classic Visitor pattern.

5. ClassVisitor: Visiting the Entire Class

ClassVisitor is responsible for class-level information.

One of the most important methods:

JAVA

public void visit(
        int version,
        int access,
        String name,
        String signature,
        String superName,
        String[] interfaces)

For example:

JAVA

public class UserService
        extends BaseService
        implements UserApi {
}

ASM can obtain:

TEXT

name
    com/example/UserService

superName
    com/example/BaseService

interfaces
    com/example/UserApi

Example:

JAVA

ClassReader reader =
        new ClassReader("com.example.UserService");

reader.accept(
    new ClassVisitor(Opcodes.ASM9) {

        @Override
        public void visit(
                int version,
                int access,
                String name,
                String signature,
                String superName,
                String[] interfaces) {

            System.out.println("class = " + name);
            System.out.println("super = " + superName);
        }
    },
    0
);

Here it's easy to encounter the first important concept of ASM:

TEXT

Internal Name

In Java:

TEXT

java.lang.String

In ASM / JVM, it's often represented as:

TEXT

java/lang/String

That is:

TEXT

Java Class Name

java.lang.String

        ↓

Internal Name

java/lang/String

6. MethodVisitor: Visiting Methods

When ClassReader parses a method, it calls:

JAVA

visitMethod(...)

For example:

JAVA

@Override
public MethodVisitor visitMethod(
        int access,
        String name,
        String descriptor,
        String signature,
        String[] exceptions) {

    System.out.println(name);
    System.out.println(descriptor);

    return super.visitMethod(
            access,
            name,
            descriptor,
            signature,
            exceptions);
}

Assuming a Java method:

JAVA

public User findById(long id)

The descriptor ASM sees is:

TEXT

(J)Lcom/example/User;

This involves JVM type descriptors.

7. Type and Descriptor

JVM doesn't directly use:

TEXT

int
String
User
long[]

to describe types. Instead, it has its own descriptor format.

Common types:

TEXT

Java                   Descriptor

void                   V
boolean                Z
byte                   B
char                   C
short                  S
int                    I
float                  F
long                   J
double                 D

String                 Ljava/lang/String;
User                   Lcom/example/User;
long[]                 [J
String[]               [Ljava/lang/String;

For a method:

JAVA

User find(String name, long id)

The descriptor:

TEXT

(Ljava/lang/String;J)Lcom/example/User;

The structure is:

TEXT

(parameter types...)return type

Therefore:

TEXT

(Ljava/lang/String;J)Lcom/example/User;
 │                 │  └───────────────── User
 │                 └──────────────────── long
 └────────────────────────────────────── String

ASM provides Type to help handle descriptors:

JAVA

Type[] args =
        Type.getArgumentTypes(descriptor);

Type returnType =
        Type.getReturnType(descriptor);

Therefore, when reading ASM code, you must distinguish these three concepts:

TEXT

Java Name
    java.lang.String

Internal Name
    java/lang/String

Descriptor
    Ljava/lang/String;

8. AnnotationVisitor: Reading Annotations

Assuming:

JAVA

@Component("userService")
public class UserService {
}

When ClassReader discovers an annotation, it calls:

JAVA

visitAnnotation(...)

For example:

JAVA

@Override
public AnnotationVisitor visitAnnotation(
        String descriptor,
        boolean visible) {

    System.out.println(descriptor);

    return new AnnotationVisitor(Opcodes.ASM9) {

        @Override
        public void visit(
                String name,
                Object value) {

            System.out.println(
                    name + " = " + value
            );
        }
    };
}

You might get:

TEXT

Lorg/springframework/stereotype/Component;

value = userService

Therefore:

JAVA

@Component("userService")

In ASM's eyes, roughly becomes:

TEXT

Annotation

descriptor:
Lorg/springframework/stereotype/Component;

attributes:

value
    ↓
"userService"

This is exactly the important foundation for Spring's annotation metadata reading.

9. FieldVisitor

Fields correspond to:

JAVA

visitField(...)

For example:

JAVA

private String username;

ASM can obtain:

TEXT

access
    private

name
    username

descriptor
    Ljava/lang/String;

The returned:

JAVA

FieldVisitor

can also continue reading:

TEXT

field annotations
field type annotations
field attributes

Therefore, Visitors are hierarchical:

TEXT

ClassVisitor
│
├─ AnnotationVisitor
│
├─ FieldVisitor
│    └─ AnnotationVisitor
│
└─ MethodVisitor
     ├─ AnnotationVisitor
     └─ bytecode instructions

10. MethodVisitor Can Not Only See Methods, But Also Instructions

MethodVisitor's most important capability is visiting JVM instructions inside methods.

For example:

JAVA

public int add(int a, int b) {
    return a + b;
}

After compilation, the core bytecode is similar to:

TEXT

ILOAD 1
ILOAD 2
IADD
IRETURN

Meaning:

TEXT

ILOAD 1
    ↓
Push local variable 1 onto operand stack

ILOAD 2
    ↓
Push local variable 2 onto operand stack

IADD
    ↓
Pop two ints, add them, push result onto stack

IRETURN
    ↓
Return int

ASM can observe these instructions through:

JAVA

visitVarInsn(...)
visitInsn(...)
visitMethodInsn(...)
visitFieldInsn(...)
visitJumpInsn(...)

For example:

JAVA

@Override
public void visitInsn(int opcode) {
    System.out.println(opcode);
}

Therefore:

TEXT

MethodVisitor

has entered the actual JVM bytecode layer.

11. Opcodes: JVM Instructions and Flag Constants

ASM extensively uses:

JAVA

Opcodes

It mainly defines three types of things.

The first type is JVM instructions:

JAVA

Opcodes.ILOAD
Opcodes.ALOAD
Opcodes.IADD
Opcodes.RETURN
Opcodes.IRETURN

Opcodes.GETFIELD
Opcodes.PUTFIELD

Opcodes.INVOKEVIRTUAL
Opcodes.INVOKESTATIC

Opcodes.NEW

The second type is access flags:

JAVA

Opcodes.ACC_PUBLIC
Opcodes.ACC_PRIVATE
Opcodes.ACC_PROTECTED
Opcodes.ACC_STATIC
Opcodes.ACC_FINAL
Opcodes.ACC_ABSTRACT
Opcodes.ACC_INTERFACE

For example:

JAVA

public static final

essentially corresponds to multiple bit flags:

TEXT

ACC_PUBLIC
|
ACC_STATIC
|
ACC_FINAL

The third type is versions:

JAVA

Opcodes.ASM9
Opcodes.V17
Opcodes.V21

Note:

JAVA

Opcodes.ASM9

represents the ASM API version;

JAVA

Opcodes.V21

represents the Java Class File version.

These are not the same concept.

12. Label: Positions in Bytecode

Java:

JAVA

if (age > 18) {
    work();
}

After compilation, there's no actual JVM if code block.

At the底层, it's more like:

TEXT

ILOAD age

IF_ICMPLE L1

INVOKEVIRTUAL work

L1:
RETURN

Where:

TEXT

L1

is a bytecode position.

ASM uses:

JAVA

Label label = new Label();

to represent such positions.

Then:

JAVA

visitJumpInsn(..., label);

Finally:

JAVA

visitLabel(label);

Therefore:

TEXT

Label
≈
Symbolic address in bytecode

It's heavily used for:

TEXT

if
goto
switch
loops
try-catch
line numbers
local variable scope
StackMapFrame

13. Handle and invokedynamic

Handle is used to describe JVM Method Handles.

It mainly appears in:

TEXT

invokedynamic
Lambda
Dynamic language support
Bootstrap Method

For example:

JAVA

Runnable r = () -> doSomething();

The Java compiler usually doesn't simply generate an anonymous inner class, but uses:

TEXT

invokedynamic

and associates:

TEXT

LambdaMetafactory

ASM uses:

JAVA

Handle

to describe the corresponding method handle information:

TEXT

owner
name
descriptor
invoke kind

This part already involves JVM dynamic invocation mechanisms and can be skipped when reading basic Spring ASM code.

14. ClassWriter: Generating `.class`

ClassReader:

TEXT

byte[] → class information

While ClassWriter:

TEXT

class information → byte[]

For example:

JAVA

ClassWriter writer =
        new ClassWriter(0);

writer.visit(
        Opcodes.V21,
        Opcodes.ACC_PUBLIC,
        "com/example/Hello",
        null,
        "java/lang/Object",
        null
);

Then define a method:

JAVA

MethodVisitor mv =
        writer.visitMethod(
            Opcodes.ACC_PUBLIC,
            "hello",
            "()V",
            null,
            null
        );

mv.visitCode();

mv.visitInsn(Opcodes.RETURN);

mv.visitMaxs(0, 1);
mv.visitEnd();

writer.visitEnd();

Finally:

JAVA

byte[] bytes =
        writer.toByteArray();

These bytes can form a real JVM class.

15. Modifying Existing Classes

A more common way to enhance bytecode with ASM is:

TEXT

Original class
     ↓
ClassReader
     ↓
Custom Visitor
     ↓
ClassWriter
     ↓
New class

Code structure:

JAVA

ClassReader reader =
        new ClassReader(bytes);

ClassWriter writer =
        new ClassWriter(
            reader,
            ClassWriter.COMPUTE_FRAMES
        );

ClassVisitor visitor =
        new ClassVisitor(
            Opcodes.ASM9,
            writer
        ) {

            @Override
            public MethodVisitor visitMethod(
                    int access,
                    String name,
                    String descriptor,
                    String signature,
                    String[] exceptions) {

                MethodVisitor mv =
                        super.visitMethod(
                            access,
                            name,
                            descriptor,
                            signature,
                            exceptions
                        );

                // Can wrap MethodVisitor

                return mv;
            }
        };

reader.accept(visitor, 0);

byte[] result =
        writer.toByteArray();

This reflects a very important design of the ASM Visitor API:

TEXT

ClassReader
     ↓
Visitor A
     ↓
Visitor B
     ↓
Visitor C
     ↓
ClassWriter

Each Visitor layer can:

TEXT

Observe
Modify
Delete
Add
Forward

events.

For example, deleting a method:

JAVA

@Override
public MethodVisitor visitMethod(
        int access,
        String name,
        String descriptor,
        String signature,
        String[] exceptions) {

    if ("deleteMe".equals(name)) {
        return null;
    }

    return super.visitMethod(
            access,
            name,
            descriptor,
            signature,
            exceptions
    );
}

The logic is:

TEXT

ClassReader
    ↓
Discover deleteMe()
    ↓
Custom Visitor
    ↓
Return null
    ↓
Event not passed to ClassWriter
    ↓
Method doesn't exist in generated new class

So ASM's Visitor is also a very natural bytecode filter chain.

16. The Writer Series Classes

In ASM, there are:

TEXT

ClassWriter
MethodWriter
FieldWriter
AnnotationWriter
ModuleWriter
RecordComponentWriter

These can be uniformly understood as:

The bytecode writing implementations corresponding to the Visitor API.

The relationships are roughly:

TEXT

ClassVisitor
    ↑
ClassWriter

MethodVisitor
    ↑
MethodWriter

FieldVisitor
    ↑
FieldWriter

AnnotationVisitor
    ↑
AnnotationWriter

ModuleVisitor
    ↑
ModuleWriter

RecordComponentVisitor
    ↑
RecordComponentWriter

For example, developers face:

JAVA

MethodVisitor.visitInsn(...)

But internally, ASM eventually needs to convert this call into actual:

TEXT

opcode byte

written into the Class File.

This work is mainly done by:

TEXT

MethodWriter

17. ByteVector

The final .class is:

TEXT

byte[]

So internally, ASM needs to continuously write:

TEXT

u1
u2
u4
u8
UTF-8
constant pool
method
attribute
bytecode

ASM uses:

JAVA

ByteVector

to maintain a dynamically expandable byte buffer.

It can be simply compared to:

TEXT

StringBuilder
    ↓
Dynamically construct String

ByteVector
    ↓
Dynamically construct byte[]

It's part of ASM's internal infrastructure and generally doesn't need to be used directly.

18. Symbol and SymbolTable

Class Files have a very important region:

TEXT

constant_pool

That is, the constant pool.

For example:

TEXT

#1 Utf8
    java/lang/Object

#2 Class
    #1

#3 Utf8
    <init>

#4 Utf8
    ()V

#5 NameAndType
    #3:#4

ASM must maintain the constant pool when generating classes.

If the same:

TEXT

java/lang/String

is used 100 times, you can't simply generate 100 identical constants.

Therefore:

TEXT

SymbolTable

is responsible for:

TEXT

Constant lookup
Constant deduplication
constant pool index allocation
Bootstrap Method management

And:

TEXT

Symbol

is used to describe symbols within it.

The relationship can be understood as:

TEXT

ClassWriter
    ↓
SymbolTable
    ↓
Symbol
    ↓
constant_pool

If you dive into ClassWriter source code later, this group of classes is very important.

19. Attribute

A lot of information in Class Files is expressed through Attributes:

TEXT

Code
Signature
SourceFile
LineNumberTable
LocalVariableTable
StackMapTable
RuntimeVisibleAnnotations
BootstrapMethods

ASM has special support for standard Attributes.

Attribute mainly provides an extension mechanism allowing ASM to handle custom or additional Class File Attributes.

At the basic learning stage, it's enough to know it corresponds to:

TEXT

Class File Attribute

20. Frame, CurrentFrame, and Edge

This group is clearly a more complex part of ASM.

They mainly serve:

TEXT

StackMapFrame
JVM bytecode verification
Control flow analysis
Maximum stack calculation

JVM method execution depends on:

TEXT

Local Variables
+
Operand Stack

For example, at a certain bytecode position:

TEXT

locals:

0 → User
1 → int
2 → String

stack:

0 → Long

This is an execution state.

In modern Class Files:

TEXT

StackMapTable

records type states at key positions, helping the JVM verifier verify whether bytecode is legal.

ASM can automatically calculate:

JAVA

new ClassWriter(
    ClassWriter.COMPUTE_FRAMES
);

This means ASM must analyze:

TEXT

Method bytecode
    ↓
Divide into Basic Blocks
    ↓
Build control flow
    ↓
Simulate Operand Stack
    ↓
Propagate local variable types
    ↓
Type merging across branches
    ↓
Calculate Frame
    ↓
Generate StackMapTable

Where:

TEXT

Frame

represents a stack frame state.

TEXT

CurrentFrame

is used for the current Frame during bytecode simulation execution.

TEXT

Edge

represents edges between basic blocks in the control flow graph:

TEXT

       ┌──── block B ────┐
       │                 ↓
block A                 block D
       │                 ↑
       └──── block C ────┘

Here:

TEXT

A → B
A → C
B → D
C → D

Each connection can be viewed as an Edge.

This part already involves compilation principles and JVM verifier, and is not recommended as a focus for ASM beginner reading.

21. Handler

Handler corresponds to the JVM exception table.

Java:

JAVA

try {
    service.execute();
} catch (Exception e) {
    handle(e);
}

In the JVM, there are no actual:

TEXT

try instruction
catch instruction

Instead, it's described through the Exception Table:

TEXT

start    end    handler    type

L0       L1     L2         java/lang/Exception

Meaning:

TEXT

During execution in range L0 ~ L1

If java/lang/Exception occurs

Jump to L2

Internally, ASM uses Handler to maintain such exception handling relationships.

22. TypeReference and TypePath

Regular annotations:

JAVA

@Deprecated
class User {
}

Only need to know:

TEXT

Annotation belongs to User

But Java also supports Type Annotations:

JAVA

List<@NotNull String>

Even:

JAVA

Map<
    String,
    List<@Nullable User>
>

ASM must describe:

TEXT

Where exactly is @Nullable marked?

TypeReference is used to describe what type position an annotation targets.

TypePath continues to describe the path within complex type structures.

It can be understood as:

TEXT

Map<String, List<@Nullable User>>
        │
        └─ Second generic parameter
                 │
                 └─ List
                     │
                     └─ First generic parameter
                            │
                            └─ User

TypePath is responsible for expressing this "path to which type node".

23. ModuleVisitor and RecordComponentVisitor

ModuleVisitor corresponds to Java 9 Modules:

JAVA

module com.example.app {

    requires java.sql;

    exports com.example.api;
}

ASM can visit:

TEXT

requires
exports
opens
uses
provides

ModuleWriter is responsible for generating the corresponding information.

RecordComponentVisitor corresponds to Java Records:

JAVA

record User(
    String name,
    int age
) {
}

Can visit Record Component's:

TEXT

name
descriptor
signature
annotation
type annotation

RecordComponentWriter is responsible for writing.

24. ConstantDynamic

Traditional Class File constant pools contain:

TEXT

Integer
Float
Long
Double
String
Class
MethodRef
...

Modern JVMs introduce:

TEXT

CONSTANT_Dynamic

ASM corresponds to:

JAVA

ConstantDynamic

It allows a constant's actual value to be dynamically calculated through Bootstrap Methods.

It can be compared to invokedynamic:

TEXT

invokedynamic
    ↓
Dynamically determine call site

CONSTANT_Dynamic
    ↓
Dynamically determine constant value

This belongs to JVM's more advanced dynamic linking capabilities.

25. SpringAsmInfo

SpringAsmInfo is an adaptation class added by Spring itself and doesn't belong to standard ASM core concepts.

Spring Framework places ASM in the:

TEXT

org.springframework.asm

namespace and maintains its own ASM API version.

Therefore, you can understand:

TEXT

SpringAsmInfo

as a layer of version information definition between Spring and the built-in ASM version.

26. ClassTooLargeException and MethodTooLargeException

These two exceptions come from limitations inherent in the JVM Class File format itself.

MethodTooLargeException indicates that the bytecode generated for a single method is too large.

JVM's Code Attribute has a limit on code length for a single method:

TEXT

code_length < 65536

Therefore, a method's bytecode can be at most approximately:

TEXT

65535 bytes

If exceeded, ASM cannot generate a valid Class File.

ClassTooLargeException is usually related to the Class File constant pool capacity limit.

Because:

TEXT

constant_pool_count

is represented using u2, there's an upper limit of approximately 65535 items in the constant pool.

27. ASM's Actual Position in Spring

After understanding ASM, the Spring usage chain becomes much clearer.

When Spring does classpath scanning, there's roughly this relationship:

TEXT

classpath
    ↓
Discover .class Resource
    ↓
MetadataReader
    ↓
Read Class Metadata
    ↓
ASM ClassReader
    ↓
Parse class
    ↓
Read:

class name
parent class
interfaces
access flags
annotations
methods
method annotations

Ultimately, Spring's upper layer obtains:

TEXT

ClassMetadata
AnnotationMetadata
MethodMetadata

Instead of directly facing:

TEXT

ClassReader
ClassVisitor
MethodVisitor

Therefore, the entire layering can be understood as:

TEXT

Spring High Level

ClassPathScanningCandidateComponentProvider
ConfigurationClassParser
        ↓

Spring Metadata Abstraction

MetadataReader
ClassMetadata
AnnotationMetadata
MethodMetadata
        ↓

ASM

ClassReader
ClassVisitor
MethodVisitor
AnnotationVisitor
        ↓

JVM

Class File

ASM is the底层 bridge between Spring's metadata system and JVM Class Files.

28. The Difference Between ASM and Reflection

Both can obtain class information, but they're at completely different stages.

TEXT

                Java Class Information

          ┌─────────┴─────────┐
          ↓                   ↓

        ASM               Reflection
          ↓                   ↓

Read .class             Operate on Class<?>
          ↓                   ↓

No requirement for      Class already in JVM
class to be loaded       ↓
          ↓                   ↓

Bytecode layer           Java runtime layer

For example, if Spring just wants to know:

TEXT

Does UserService have @Component?

ASM is perfect.

But after a Bean has been created and you need:

JAVA

method.invoke(bean, args);

that's in Reflection's domain.

Therefore:

TEXT

ASM

solves:

What's in this .class file?

While:

TEXT

Reflection

solves:

What is this already-loaded Java type in the JVM, and how to operate on it?

This is a very important boundary when reading Spring source code.

29. Responsibilities of ASM Classes

By reading priority, this package can be divided into four layers.

The first layer is the core API you must understand:

TEXT

ClassReader
ClassVisitor
ClassWriter

MethodVisitor
FieldVisitor
AnnotationVisitor

Opcodes
Type
Label

After understanding these classes, you can already understand most basic ASM calls.

The second layer is modern JVM structure descriptions:

TEXT

Handle
ConstantDynamic
TypeReference
TypePath

ModuleVisitor
RecordComponentVisitor

Dive deeper when you encounter related features.

The third layer is Writer internal implementations:

TEXT

MethodWriter
FieldWriter
AnnotationWriter
ModuleWriter
RecordComponentWriter

ByteVector
Symbol
SymbolTable
Attribute
Context

Mainly used to understand how ASM truly generates Class Files.

The fourth layer is bytecode analysis:

TEXT

Frame
CurrentFrame
Edge
Handler

This part requires knowledge of:

TEXT

JVM:

Operand Stack
Local Variables
Basic Block
Control Flow Graph
StackMapTable
Verifier

as a foundation, and is not suitable as an entry point for reading ASM.

30. Reading Order

If the goal is to read Spring Framework source code, it's not recommended to start by reading classes in the org.springframework.asm package one by one.

A more suitable route is:

TEXT

Phase 1: Establish JVM Class File basics

Class File
descriptor
internal name
constant pool
opcode
operand stack
local variable

Then read:

TEXT

Type
Opcodes
Label

Understand the basic language ASM uses.

TEXT

ClassReader
    ↓
ClassVisitor
    ↓
MethodVisitor
    ↓
AnnotationVisitor

Focus on understanding:

TEXT

ClassReader.accept(visitor)

how it drives the Visitor.

Then reverse-understand:

TEXT

ClassWriter
    ↓
MethodWriter
    ↓
ByteVector
    ↓
SymbolTable

Understand how ASM reconstructs Class Files.

Finally, if needed, go into:

TEXT

Frame
CurrentFrame
Edge
Handler

Study:

TEXT

CFG
Frame calculation
StackMapTable
Bytecode verification

If the main goal is Spring source code, after mastering:

TEXT

ClassReader
Visitor
Type
Opcodes
Label

you should return to Spring's upper layer and continue reading along:

TEXT

MetadataReader
    ↓
AnnotationMetadata
    ↓
Component scanning
    ↓
Configuration class parsing

ASM is a底层 implementation means for Spring, not the core business model of the Spring container.

31. Final Mental Model

When you see:

TEXT

org.springframework.asm

First think:

TEXT

Directly operate on JVM Class Files

When you see:

TEXT

ClassReader

Think:

TEXT

byte[] → parse class

When you see:

TEXT

ClassVisitor
MethodVisitor
AnnotationVisitor

Think:

TEXT

Visit events generated during ClassReader parsing

When you see:

TEXT

ClassWriter

Think:

TEXT

Visit events → byte[]

When you see:

TEXT

Type

Think:

TEXT

JVM descriptor

When you see:

TEXT

Opcodes

Think:

TEXT

JVM instructions and access flags

When you see:

TEXT

Label

Think:

TEXT

Bytecode position / jump target

When you see:

TEXT

SymbolTable

Think:

TEXT

Class File constant pool

When you see:

TEXT

Frame
Edge

Think:

TEXT

Operand stack + local variables + control flow analysis

And from the overall Spring architecture perspective:

TEXT

Spring
  │
  │ Needs to know what annotations and structure a class has
  ↓
MetadataReader
  ↓
ASM
  ↓
ClassReader
  ↓
Parse .class directly
  ↓
Don't need to obtain Class<?> first

This is the core value of org.springframework.asm in Spring Framework.

Spring Source Code Series: Spring ASM Bytecode Processing Mechanism

1. Why Spring Needs ASM

2. ASM Operates on Java Source Code? No - ASM Operates on JVM Class Files

3. ASM's Core Design: Reader + Visitor + Writer

4. ClassReader: Reading .class

5. ClassVisitor: Visiting the Entire Class

6. MethodVisitor: Visiting Methods

7. Type and Descriptor

8. AnnotationVisitor: Reading Annotations

9. FieldVisitor

10. MethodVisitor Can Not Only See Methods, But Also Instructions

11. Opcodes: JVM Instructions and Flag Constants

12. Label: Positions in Bytecode

13. Handle and invokedynamic

14. ClassWriter: Generating .class

15. Modifying Existing Classes

16. The Writer Series Classes

17. ByteVector

18. Symbol and SymbolTable

19. Attribute

20. Frame, CurrentFrame, and Edge

21. Handler

22. TypeReference and TypePath

23. ModuleVisitor and RecordComponentVisitor

24. ConstantDynamic

25. SpringAsmInfo

26. ClassTooLargeException and MethodTooLargeException

27. ASM's Actual Position in Spring

28. The Difference Between ASM and Reflection

29. Responsibilities of ASM Classes

30. Reading Order

31. Final Mental Model

4. ClassReader: Reading `.class`

14. ClassWriter: Generating `.class`