ASM 泛型签名全解析从 Signature 语法规则到 SignatureVisitor 字节码读写实战【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址: https://gitcode.com/gh_mirrors/code/CodeGuide泛型信息在 class 文件中并不存在于类型/方法描述符里而是以独立的签名Signature形式附加在类、字段和方法声明上。本文基于 CodeGuide 仓库中《ASM 文档》的 4.1 泛型 一章系统讲解类型签名、方法签名、类签名的语法规则深入剖析org.objectweb.asm.signature包中SignatureVisitor、SignatureReader、SignatureWriter三个核心组件并结合仓库源码给出一个可运行的签名重命名适配器帮助你掌握用 ASM 读写、转换泛型签名的完整技能。泛型信息为什么不能放进描述符诸如ListE之类的泛型类以及使用它们的类包含了有关它们所声明或使用的泛型的信息。这一信息不是由字节码指令在运行时使用的但可以通过反射 API 访问还可以供编译器在分离编译separate compilation时使用。为什么不能把泛型直接塞进类型描述符或方法描述符关键原因在于后向兼容类型和方法描述符的定义远早于 Java 5 对泛型的引入一旦修改描述符格式所有旧版本的 class 文件、JVM 和既有工具链都将被破坏。因此泛型信息被保存在称为**签名signature**的类似构造中与描述符并列存在。从 class 文件结构上看见 2.1 结构已编译类中内部名internal name表示类/接口类型如String→java/lang/String类型描述符表示字段类型基元类型用单字符Z、C、B、S、I、F、J、D类类型为L 内部名 ;数组为[ 元素描述符方法描述符表示参数类型与返回类型如(I)V。在涉及泛型时除了描述符之外签名还会存储在类、字段和方法声明中。需要特别强调的是泛型不会影响方法的字节码——编译器用泛型执行静态类型检查但会在必要时重新插入类型转换指令就像这些方法未被泛型化一样进行编译。也就是说泛型签名对 JVM 指令执行毫无影响它是一份元信息供反射 API 和编译期工具读取。签名语法递归定义下的三类签名与类型和方法描述符不同类型签名的语法非常复杂这源于泛型的递归本质——一个泛型可以将另一个泛型作为参数例如ListListE。其语法规则如下完整规则见《Java 虚拟机规范》TypeSignature: Z | C | B | S | I | F | J | D | FieldTypeSignature FieldTypeSignature: ClassTypeSignature | [ TypeSignature | TypeVar ClassTypeSignature: L Id ( / Id )* TypeArgs? ( . Id TypeArgs? )* ; TypeArgs: TypeArg TypeArg: * | ( | - )? FieldTypeSignature TypeVar: T Id ;逐条解读这几条规则第一条规则类型签名TypeSignature或者是一个基元类型描述符Z C B S I F J D或者是一个字段类型签名FieldTypeSignature。基元类型没有泛型可言所以直接复用描述符中的单字符表示。第二条规则字段类型签名可以是类类型签名ClassTypeSignature、数组类型签名[加类型签名或类型变量TypeVar。注意数组可以递归嵌套这也是签名可以变得很深的原因之一。第三条规则类类型签名就是类类型描述符的扩展——在主类名之后或内部类名之后以.为前缀的尖括号中可能带有类型参数TypeArgs。L Id ( / Id )*部分与普通类描述符一致后面可选的TypeArgs?与( . Id TypeArgs? )*则承载泛型信息。第四条与第五条规则类型参数TypeArg可以是通配符*也可以是带extends 上界或-super 下界前缀的字段类型签名类型变量TypeVar则是T加标识符加;。一个类型参数本身可以是一个完整的字段类型签名带有自己的类型参数——因此签名可能非常复杂。下面这张表将 Java 源代码中的类型与其对应的类型签名一一对应是理解签名语法最直观的参考Java 类型相应的类型签名ListELjava/util/ListTE;;List?Ljava/util/List*;List? extends NumberLjava/util/ListLjava/lang/Number;;List? super IntegerLjava/util/List-Ljava/lang/Integer;;ListListString[]Ljava/util/List[Ljava/util/ListLjava/lang/String;;;HashMapK, V.HashIteratorKLjava/util/HashMapTK;TV;.HashIteratorTK;;从表中可以总结出几个重要规律类型变量E写作TE;T前缀表示这是一个类型变量无界通配符?写作*有界通配符? extends T写作T协变? super T写作-T逆变数组类型直接在元素签名前加[因此ListString[]写作[Ljava/util/ListLjava/lang/String;;泛型内部类用.分隔外层与内层如HashMapK, V.HashIteratorK中TK;TV;跟随外层类名.HashIteratorTK;跟随内层类名。方法签名在描述符之上叠加异常与形式类型参数方法签名扩展了方法描述符就像类型签名扩展了类型描述符一样。它描述了方法参数的类型签名及其返回类型的签名与方法描述符不同的是它还额外包含了两类信息该方法所抛出的异常签名前面带有^前缀可选的形式类型参数放在尖括号之间。MethodTypeSignature: TypeParams? ( TypeSignature* ) ( TypeSignature | V ) Exception* Exception: ^ClassTypeSignature | ^TypeVar TypeParams: TypeParam TypeParam: Id : FieldTypeSignature? ( : FieldTypeSignature )*形式类型参数TypeParam的规则值得留意Id : FieldTypeSignature? ( : FieldTypeSignature )*中第一个冒号后是类边界可空后续冒号后是接口边界可多个——这与 Java 语法T extends A B C的声明方式一一对应。例如以下泛型静态方法以类型变量T为参数static T Class? extends T m (int n)它对应的方法签名是T:Ljava/lang/Object;(I)Ljava/lang/ClassTT;;逐段拆解这个签名T:Ljava/lang/Object;形式类型参数声明T的类边界为Ljava/lang/Object;Java 中未显式声明边界时默认是Object(I)参数类型签名一个int与描述符中的I完全一致Ljava/lang/ClassTT;;返回类型签名即Class? extends T其中TT;表示? extends T为通配符上界TT;为类型变量T。类签名超类 接口 形式类型参数最后是类签名ClassSignature不要将它与类类型签名相混淆。类签名被定义为其超类的类型签名后面跟有所实现接口的类型签名以及可选的形式类型参数ClassSignature: TypeParams? ClassTypeSignature ClassTypeSignature*例如一个声明为CE extends ListE的类其类签名为E:Ljava/lang/Object;Ljava/util/ListTE;;这里E:Ljava/lang/Object;是形式类型参数声明Ljava/util/ListTE;;是超类ListE的类型签名实现接口时则依次列出各接口的类型签名。接口与组件SignatureVisitor 访问者模型和描述符的情况一样出于相同的效果原因见 2.3 工具 中对Type类的说明——ASM 为了避免两种表示之间的系统转换损失性能直接以编译类中的存储形式公开类型ASM API 公开签名的形式与它们在编译类中的存储形式相同。签名主要出现在ClassVisitor类的visit、visitField和visitMethod方法中分别作为可选的类签名、类型签名或方法签名参数见 2.2 接口和组件public void visit(int version, int access, String name, String signature, String superName, String[] interfaces); public FieldVisitor visitField(int access, String name, String desc, String signature, Object value); public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions);当类、字段或方法未使用泛型时这三个signature参数均为null一旦使用了泛型就必须提供对应的签名字符串。幸好ASM 在org.objectweb.asm.signature包中提供了一些基于SignatureVisitor抽象类的工具用于生成和转换签名。SignatureVisitor类的完整定义如下public abstract class SignatureVisitor { public final static char EXTENDS ; public final static char SUPER -; public final static char INSTANCEOF ; public SignatureVisitor(int api); public void visitFormalTypeParameter(String name); public SignatureVisitor visitClassBound(); public SignatureVisitor visitInterfaceBound(); public SignatureVisitor visitSuperclass(); public SignatureVisitor visitInterface(); public SignatureVisitor visitParameterType(); public SignatureVisitor visitReturnType(); public SignatureVisitor visitExceptionType(); public void visitBaseType(char descriptor); public void visitTypeVariable(String name); public SignatureVisitor visitArrayType(); public void visitClassType(String name); public void visitInnerClassType(String name); public void visitTypeArgument(); public SignatureVisitor visitTypeArgument(char wildcard); public void visitEnd(); }三个静态常量EXTENDS、SUPER、INSTANCEOF对应、-、三个通配符标记表示? extends上界-表示? super下界表示?确切类型参数常用于Class...等场景。这个抽象类同时用于访问类型签名、方法签名和类签名。用于类型签名的方法上文中以粗体区分的visitBaseType、visitArrayType、visitTypeVariable、visitClassType等必须按以下顺序调用它正好反映了前面给出的语法规则——注意其中有两个方法返回了SignatureVisitor这正是类型签名递归定义的直接体现visitBaseType | visitArrayType | visitTypeVariable | ( visitClassType visitTypeArgument* ( visitInnerClassType visitTypeArgument* )* visitEnd ) )用于访问方法签名的方法调用顺序为( visitFormalTypeParameter visitClassBound? visitInterfaceBound* )* visitParameterType* visitReturnType visitExceptionType*用于访问类签名的方法调用顺序为( visitFormalTypeParameter visitClassBound? visitInterfaceBound* )* visitSuperClass visitInterface*这些方法大多返回一个SignatureVisitor它是准备用来访问嵌套类型签名的。有一个关键的使用约束与ClassVisitor不同SignatureVisitor返回的嵌套SignatureVisitor不得为 null而且必须顺序使用——在完全访问完一个嵌套签名之前不得访问父访问器的任何方法。SignatureReader 与 SignatureWriter和类的情况一样ASM 基于SignatureVisitor这个 API 提供了两个组件SignatureReader分析一个签名字符串并针对一个给定的签名访问器调用适当的访问方法相当于事件产生器SignatureWriter基于它接收到的方法调用生成一个签名字符串相当于事件使用器。利用与类和方法相同的原理这两个类可用于生成和转换签名。例如假定我们希望对出现在某些签名中的类名进行重命名这一效果可以用下面的签名适配器完成。除visitClassType和visitInnerClassType方法之外它将自己接收到的所有其他方法调用都不加修改地转发这里假设sv方法总是返回thisSignatureWriter就属于这种情况public class RenameSignatureAdapter extends SignatureVisitor { private SignatureVisitor sv; private MapString, String renaming; private String oldName; public RenameSignatureAdapter(SignatureVisitor sv, MapString, String renaming) { super(ASM4); this.sv sv; this.renaming renaming; } public void visitFormalTypeParameter(String name) { sv.visitFormalTypeParameter(name); } public SignatureVisitor visitClassBound() { sv.visitClassBound(); return this; } public SignatureVisitor visitInterfaceBound() { sv.visitInterfaceBound(); return this; } ... public void visitClassType(String name) { oldName name; String newName renaming.get(oldName); sv.visitClassType(newName null ? name : newName); } public void visitInnerClassType(String name) { oldName oldName . name; String newName renaming.get(oldName); sv.visitInnerClassType(newName null ? name : newName); } public void visitTypeArgument() { sv.visitTypeArgument(); } public SignatureVisitor visitTypeArgument(char wildcard) { sv.visitTypeArgument(wildcard); return this; } public void visitEnd() { sv.visitEnd(); } }这个适配器的实现要点转发类visitFormalTypeParameter、visitTypeArgument、visitEnd等方法原样转发返回thisvisitClassBound、visitInterfaceBound、visitTypeArgument(char)等需要返回嵌套访问器的方法直接返回this使后续调用继续流向同一个适配器即顺序使用约束的落地写法重命名逻辑visitClassType记录当前的oldName并查表替换visitInnerClassType则用outer.inner拼接出完整的内部类名再查表从而正确处理HashMapK,V.HashIteratorK这类嵌套内部类签名。将该适配器与SignatureWriter、SignatureReader串联起来即可完成一次完整的签名转换。以下代码的结果为LATK;TV;.BTK;;String s Ljava/util/HashMapTK;TV;.HashIteratorTK;;; MapString, String renaming new HashMapString, String(); renaming.put(java/util/HashMap, A); renaming.put(java/util/HashMap.HashIterator, B); SignatureWriter sw new SignatureWriter(); SignatureVisitor sa new RenameSignatureAdapter(sw, renaming); SignatureReader sr new SignatureReader(s); sr.acceptType(sa); sw.toString();整个数据流清晰可见SignatureReader解析签名字符串s通过acceptType(sa)把解析事件派发给适配器RenameSignatureAdapter在visitClassType/visitInnerClassType中完成HashMap→A、HashMap.HashIterator→B的重命名其余事件原样透传事件最终落到SignatureWriter上由其重新拼装出新的签名字符串。注意这里的acceptType是针对类型签名的分析方法——SignatureReader还提供accept方法用于分析类签名/方法签名对应入口是visit与visitField/visitMethod中传递的签名参数。实践如何用工具反查一个泛型对应的签名在 2.3 工具 一节给出的TraceClassVisitor和ASMifier类可以以内部形式打印类文件中包含的签名。利用它们可以通过以下方式找出与一个给定泛型相对应的签名编写一个使用了目标泛型的 Java 类用javac编译它得到.class文件用 ASM 命令行工具或自定义的TraceClassVisitor打印器查看编译产物中记录的真实签名。例如使用ASMifier的命令行方式见 2.3 工具 中的命令行示例java -classpath asm.jar:asm-util.jar org.objectweb.asm.util.ASMifier java.lang.RunnableASMifier会打印出用 ASM API 生成该类的完整 Java 源代码ClassWriter、visitMethod等调用其中visit方法的signature参数、visitField/visitMethod的signature参数即为所需的签名原文。同理把TraceClassVisitor挂在ClassReader与ClassWriter之间也可以在输出轨迹中直接看到// signature注释行标注的签名内容。树 API 视角泛型为什么没有对应的 Node如果你转向 ASM 的树 APIorg.objectweb.asm.tree包会发现一个值得注意的设计取舍树 API 没有提供对泛型的任何支持。事实上它用签名表示泛型这一点与核心 API 中一样但却没有提供与SignatureVisitor对应的SignatureNode类——尽管这也是可能的至少使用几个 Node 类来区分类型、方法和类签名会很方便。这一点在仓库的 9.1 泛型 中有明确说明。因此当你在树 API 中操作ClassNode、FieldNode、MethodNode时泛型信息仍然以signature字符串字段的形式原样保留如果需要对其中的类名、类型变量进行程序化修改仍需借助SignatureReader/SignatureWriter解析和重建签名这与核心 API 的处理方式完全一致。小结泛型与字节码解耦泛型签名不影响方法字节码编译器完成静态类型检查后会在必要时插入类型转换指令签名只是 class 文件中的一份元数据供反射 API 与编译器分离编译使用三种签名、一套语法类型签名TE;、*、、-、数组[、内部类.、方法签名参数/返回类型签名 ^异常 尖括号形式类型参数、类签名形式类型参数 超类 接口全部由递归文法定义一套访问者模型SignatureVisitor是签名读写与转换的统一接口SignatureReader解析产生事件SignatureWriter消费事件生成签名适配器在中间完成过滤与改写嵌套访问器不得为 null、必须顺序使用工具链齐备TraceClassVisitor、ASMifier可以把编译产物中的签名原样打印出来是反查、调试签名语法的利器。如需继续深入可依次阅读仓库内的相关章节2.1 结构描述符与内部名基础、2.2 接口和组件ClassVisitor签名参数、2.3 工具TraceClassVisitor/ASMifier用法、4.2 注释另一类元数据以及 9.1 泛型树 API 下的处理方式。【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址: https://gitcode.com/gh_mirrors/code/CodeGuide创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ASM 泛型签名全解析：从 Signature 语法规则到 SignatureVisitor 字节码读写实战
ASM 泛型签名全解析从 Signature 语法规则到 SignatureVisitor 字节码读写实战【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址: https://gitcode.com/gh_mirrors/code/CodeGuide泛型信息在 class 文件中并不存在于类型/方法描述符里而是以独立的签名Signature形式附加在类、字段和方法声明上。本文基于 CodeGuide 仓库中《ASM 文档》的 4.1 泛型 一章系统讲解类型签名、方法签名、类签名的语法规则深入剖析org.objectweb.asm.signature包中SignatureVisitor、SignatureReader、SignatureWriter三个核心组件并结合仓库源码给出一个可运行的签名重命名适配器帮助你掌握用 ASM 读写、转换泛型签名的完整技能。泛型信息为什么不能放进描述符诸如ListE之类的泛型类以及使用它们的类包含了有关它们所声明或使用的泛型的信息。这一信息不是由字节码指令在运行时使用的但可以通过反射 API 访问还可以供编译器在分离编译separate compilation时使用。为什么不能把泛型直接塞进类型描述符或方法描述符关键原因在于后向兼容类型和方法描述符的定义远早于 Java 5 对泛型的引入一旦修改描述符格式所有旧版本的 class 文件、JVM 和既有工具链都将被破坏。因此泛型信息被保存在称为**签名signature**的类似构造中与描述符并列存在。从 class 文件结构上看见 2.1 结构已编译类中内部名internal name表示类/接口类型如String→java/lang/String类型描述符表示字段类型基元类型用单字符Z、C、B、S、I、F、J、D类类型为L 内部名 ;数组为[ 元素描述符方法描述符表示参数类型与返回类型如(I)V。在涉及泛型时除了描述符之外签名还会存储在类、字段和方法声明中。需要特别强调的是泛型不会影响方法的字节码——编译器用泛型执行静态类型检查但会在必要时重新插入类型转换指令就像这些方法未被泛型化一样进行编译。也就是说泛型签名对 JVM 指令执行毫无影响它是一份元信息供反射 API 和编译期工具读取。签名语法递归定义下的三类签名与类型和方法描述符不同类型签名的语法非常复杂这源于泛型的递归本质——一个泛型可以将另一个泛型作为参数例如ListListE。其语法规则如下完整规则见《Java 虚拟机规范》TypeSignature: Z | C | B | S | I | F | J | D | FieldTypeSignature FieldTypeSignature: ClassTypeSignature | [ TypeSignature | TypeVar ClassTypeSignature: L Id ( / Id )* TypeArgs? ( . Id TypeArgs? )* ; TypeArgs: TypeArg TypeArg: * | ( | - )? FieldTypeSignature TypeVar: T Id ;逐条解读这几条规则第一条规则类型签名TypeSignature或者是一个基元类型描述符Z C B S I F J D或者是一个字段类型签名FieldTypeSignature。基元类型没有泛型可言所以直接复用描述符中的单字符表示。第二条规则字段类型签名可以是类类型签名ClassTypeSignature、数组类型签名[加类型签名或类型变量TypeVar。注意数组可以递归嵌套这也是签名可以变得很深的原因之一。第三条规则类类型签名就是类类型描述符的扩展——在主类名之后或内部类名之后以.为前缀的尖括号中可能带有类型参数TypeArgs。L Id ( / Id )*部分与普通类描述符一致后面可选的TypeArgs?与( . Id TypeArgs? )*则承载泛型信息。第四条与第五条规则类型参数TypeArg可以是通配符*也可以是带extends 上界或-super 下界前缀的字段类型签名类型变量TypeVar则是T加标识符加;。一个类型参数本身可以是一个完整的字段类型签名带有自己的类型参数——因此签名可能非常复杂。下面这张表将 Java 源代码中的类型与其对应的类型签名一一对应是理解签名语法最直观的参考Java 类型相应的类型签名ListELjava/util/ListTE;;List?Ljava/util/List*;List? extends NumberLjava/util/ListLjava/lang/Number;;List? super IntegerLjava/util/List-Ljava/lang/Integer;;ListListString[]Ljava/util/List[Ljava/util/ListLjava/lang/String;;;HashMapK, V.HashIteratorKLjava/util/HashMapTK;TV;.HashIteratorTK;;从表中可以总结出几个重要规律类型变量E写作TE;T前缀表示这是一个类型变量无界通配符?写作*有界通配符? extends T写作T协变? super T写作-T逆变数组类型直接在元素签名前加[因此ListString[]写作[Ljava/util/ListLjava/lang/String;;泛型内部类用.分隔外层与内层如HashMapK, V.HashIteratorK中TK;TV;跟随外层类名.HashIteratorTK;跟随内层类名。方法签名在描述符之上叠加异常与形式类型参数方法签名扩展了方法描述符就像类型签名扩展了类型描述符一样。它描述了方法参数的类型签名及其返回类型的签名与方法描述符不同的是它还额外包含了两类信息该方法所抛出的异常签名前面带有^前缀可选的形式类型参数放在尖括号之间。MethodTypeSignature: TypeParams? ( TypeSignature* ) ( TypeSignature | V ) Exception* Exception: ^ClassTypeSignature | ^TypeVar TypeParams: TypeParam TypeParam: Id : FieldTypeSignature? ( : FieldTypeSignature )*形式类型参数TypeParam的规则值得留意Id : FieldTypeSignature? ( : FieldTypeSignature )*中第一个冒号后是类边界可空后续冒号后是接口边界可多个——这与 Java 语法T extends A B C的声明方式一一对应。例如以下泛型静态方法以类型变量T为参数static T Class? extends T m (int n)它对应的方法签名是T:Ljava/lang/Object;(I)Ljava/lang/ClassTT;;逐段拆解这个签名T:Ljava/lang/Object;形式类型参数声明T的类边界为Ljava/lang/Object;Java 中未显式声明边界时默认是Object(I)参数类型签名一个int与描述符中的I完全一致Ljava/lang/ClassTT;;返回类型签名即Class? extends T其中TT;表示? extends T为通配符上界TT;为类型变量T。类签名超类 接口 形式类型参数最后是类签名ClassSignature不要将它与类类型签名相混淆。类签名被定义为其超类的类型签名后面跟有所实现接口的类型签名以及可选的形式类型参数ClassSignature: TypeParams? ClassTypeSignature ClassTypeSignature*例如一个声明为CE extends ListE的类其类签名为E:Ljava/lang/Object;Ljava/util/ListTE;;这里E:Ljava/lang/Object;是形式类型参数声明Ljava/util/ListTE;;是超类ListE的类型签名实现接口时则依次列出各接口的类型签名。接口与组件SignatureVisitor 访问者模型和描述符的情况一样出于相同的效果原因见 2.3 工具 中对Type类的说明——ASM 为了避免两种表示之间的系统转换损失性能直接以编译类中的存储形式公开类型ASM API 公开签名的形式与它们在编译类中的存储形式相同。签名主要出现在ClassVisitor类的visit、visitField和visitMethod方法中分别作为可选的类签名、类型签名或方法签名参数见 2.2 接口和组件public void visit(int version, int access, String name, String signature, String superName, String[] interfaces); public FieldVisitor visitField(int access, String name, String desc, String signature, Object value); public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions);当类、字段或方法未使用泛型时这三个signature参数均为null一旦使用了泛型就必须提供对应的签名字符串。幸好ASM 在org.objectweb.asm.signature包中提供了一些基于SignatureVisitor抽象类的工具用于生成和转换签名。SignatureVisitor类的完整定义如下public abstract class SignatureVisitor { public final static char EXTENDS ; public final static char SUPER -; public final static char INSTANCEOF ; public SignatureVisitor(int api); public void visitFormalTypeParameter(String name); public SignatureVisitor visitClassBound(); public SignatureVisitor visitInterfaceBound(); public SignatureVisitor visitSuperclass(); public SignatureVisitor visitInterface(); public SignatureVisitor visitParameterType(); public SignatureVisitor visitReturnType(); public SignatureVisitor visitExceptionType(); public void visitBaseType(char descriptor); public void visitTypeVariable(String name); public SignatureVisitor visitArrayType(); public void visitClassType(String name); public void visitInnerClassType(String name); public void visitTypeArgument(); public SignatureVisitor visitTypeArgument(char wildcard); public void visitEnd(); }三个静态常量EXTENDS、SUPER、INSTANCEOF对应、-、三个通配符标记表示? extends上界-表示? super下界表示?确切类型参数常用于Class...等场景。这个抽象类同时用于访问类型签名、方法签名和类签名。用于类型签名的方法上文中以粗体区分的visitBaseType、visitArrayType、visitTypeVariable、visitClassType等必须按以下顺序调用它正好反映了前面给出的语法规则——注意其中有两个方法返回了SignatureVisitor这正是类型签名递归定义的直接体现visitBaseType | visitArrayType | visitTypeVariable | ( visitClassType visitTypeArgument* ( visitInnerClassType visitTypeArgument* )* visitEnd ) )用于访问方法签名的方法调用顺序为( visitFormalTypeParameter visitClassBound? visitInterfaceBound* )* visitParameterType* visitReturnType visitExceptionType*用于访问类签名的方法调用顺序为( visitFormalTypeParameter visitClassBound? visitInterfaceBound* )* visitSuperClass visitInterface*这些方法大多返回一个SignatureVisitor它是准备用来访问嵌套类型签名的。有一个关键的使用约束与ClassVisitor不同SignatureVisitor返回的嵌套SignatureVisitor不得为 null而且必须顺序使用——在完全访问完一个嵌套签名之前不得访问父访问器的任何方法。SignatureReader 与 SignatureWriter和类的情况一样ASM 基于SignatureVisitor这个 API 提供了两个组件SignatureReader分析一个签名字符串并针对一个给定的签名访问器调用适当的访问方法相当于事件产生器SignatureWriter基于它接收到的方法调用生成一个签名字符串相当于事件使用器。利用与类和方法相同的原理这两个类可用于生成和转换签名。例如假定我们希望对出现在某些签名中的类名进行重命名这一效果可以用下面的签名适配器完成。除visitClassType和visitInnerClassType方法之外它将自己接收到的所有其他方法调用都不加修改地转发这里假设sv方法总是返回thisSignatureWriter就属于这种情况public class RenameSignatureAdapter extends SignatureVisitor { private SignatureVisitor sv; private MapString, String renaming; private String oldName; public RenameSignatureAdapter(SignatureVisitor sv, MapString, String renaming) { super(ASM4); this.sv sv; this.renaming renaming; } public void visitFormalTypeParameter(String name) { sv.visitFormalTypeParameter(name); } public SignatureVisitor visitClassBound() { sv.visitClassBound(); return this; } public SignatureVisitor visitInterfaceBound() { sv.visitInterfaceBound(); return this; } ... public void visitClassType(String name) { oldName name; String newName renaming.get(oldName); sv.visitClassType(newName null ? name : newName); } public void visitInnerClassType(String name) { oldName oldName . name; String newName renaming.get(oldName); sv.visitInnerClassType(newName null ? name : newName); } public void visitTypeArgument() { sv.visitTypeArgument(); } public SignatureVisitor visitTypeArgument(char wildcard) { sv.visitTypeArgument(wildcard); return this; } public void visitEnd() { sv.visitEnd(); } }这个适配器的实现要点转发类visitFormalTypeParameter、visitTypeArgument、visitEnd等方法原样转发返回thisvisitClassBound、visitInterfaceBound、visitTypeArgument(char)等需要返回嵌套访问器的方法直接返回this使后续调用继续流向同一个适配器即顺序使用约束的落地写法重命名逻辑visitClassType记录当前的oldName并查表替换visitInnerClassType则用outer.inner拼接出完整的内部类名再查表从而正确处理HashMapK,V.HashIteratorK这类嵌套内部类签名。将该适配器与SignatureWriter、SignatureReader串联起来即可完成一次完整的签名转换。以下代码的结果为LATK;TV;.BTK;;String s Ljava/util/HashMapTK;TV;.HashIteratorTK;;; MapString, String renaming new HashMapString, String(); renaming.put(java/util/HashMap, A); renaming.put(java/util/HashMap.HashIterator, B); SignatureWriter sw new SignatureWriter(); SignatureVisitor sa new RenameSignatureAdapter(sw, renaming); SignatureReader sr new SignatureReader(s); sr.acceptType(sa); sw.toString();整个数据流清晰可见SignatureReader解析签名字符串s通过acceptType(sa)把解析事件派发给适配器RenameSignatureAdapter在visitClassType/visitInnerClassType中完成HashMap→A、HashMap.HashIterator→B的重命名其余事件原样透传事件最终落到SignatureWriter上由其重新拼装出新的签名字符串。注意这里的acceptType是针对类型签名的分析方法——SignatureReader还提供accept方法用于分析类签名/方法签名对应入口是visit与visitField/visitMethod中传递的签名参数。实践如何用工具反查一个泛型对应的签名在 2.3 工具 一节给出的TraceClassVisitor和ASMifier类可以以内部形式打印类文件中包含的签名。利用它们可以通过以下方式找出与一个给定泛型相对应的签名编写一个使用了目标泛型的 Java 类用javac编译它得到.class文件用 ASM 命令行工具或自定义的TraceClassVisitor打印器查看编译产物中记录的真实签名。例如使用ASMifier的命令行方式见 2.3 工具 中的命令行示例java -classpath asm.jar:asm-util.jar org.objectweb.asm.util.ASMifier java.lang.RunnableASMifier会打印出用 ASM API 生成该类的完整 Java 源代码ClassWriter、visitMethod等调用其中visit方法的signature参数、visitField/visitMethod的signature参数即为所需的签名原文。同理把TraceClassVisitor挂在ClassReader与ClassWriter之间也可以在输出轨迹中直接看到// signature注释行标注的签名内容。树 API 视角泛型为什么没有对应的 Node如果你转向 ASM 的树 APIorg.objectweb.asm.tree包会发现一个值得注意的设计取舍树 API 没有提供对泛型的任何支持。事实上它用签名表示泛型这一点与核心 API 中一样但却没有提供与SignatureVisitor对应的SignatureNode类——尽管这也是可能的至少使用几个 Node 类来区分类型、方法和类签名会很方便。这一点在仓库的 9.1 泛型 中有明确说明。因此当你在树 API 中操作ClassNode、FieldNode、MethodNode时泛型信息仍然以signature字符串字段的形式原样保留如果需要对其中的类名、类型变量进行程序化修改仍需借助SignatureReader/SignatureWriter解析和重建签名这与核心 API 的处理方式完全一致。小结泛型与字节码解耦泛型签名不影响方法字节码编译器完成静态类型检查后会在必要时插入类型转换指令签名只是 class 文件中的一份元数据供反射 API 与编译器分离编译使用三种签名、一套语法类型签名TE;、*、、-、数组[、内部类.、方法签名参数/返回类型签名 ^异常 尖括号形式类型参数、类签名形式类型参数 超类 接口全部由递归文法定义一套访问者模型SignatureVisitor是签名读写与转换的统一接口SignatureReader解析产生事件SignatureWriter消费事件生成签名适配器在中间完成过滤与改写嵌套访问器不得为 null、必须顺序使用工具链齐备TraceClassVisitor、ASMifier可以把编译产物中的签名原样打印出来是反查、调试签名语法的利器。如需继续深入可依次阅读仓库内的相关章节2.1 结构描述符与内部名基础、2.2 接口和组件ClassVisitor签名参数、2.3 工具TraceClassVisitor/ASMifier用法、4.2 注释另一类元数据以及 9.1 泛型树 API 下的处理方式。【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址: https://gitcode.com/gh_mirrors/code/CodeGuide创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考