一、概述
字节码文件的跨平台性
Java语言:跨平台的语言
- 当Java源代码成功编译成字节码后,如果想在不同平台上运行,则无需再次编译。
- 这个优势已经不再那么吸引人了,Python、PHP、Perl、Ruby、Lisp等有强大的编译器。
- 跨平台似乎已经快成为一门语言必选的特性。
Java虚拟机:跨语言的平台
- Java虚拟机不和包括 Java 在内的任何语言绑定,它只与 “Class 文件” 这种特定的二进制文件格式所关联,无论使用何种语言进行软件开发,只要能将源文件编译为正确的Class文件,那么这种语言就可以在Java虚拟机上执行,可以说,统一而强大的Class文件结构,就是Java虚拟机的基石、桥梁。
所有的JVM全部遵守Java虚拟机规范,也就是说所有的JVM环境都是一样的,这样一来字节码文件可以在各种JVM上运行。想要让一个Java程序正确的运行在JVM中,Java源码就必须要被编译为符合JVM规范的字节码。
-
前端编译器的主要任务就是负责将符合Java语法规范的Java代码转换为符合JVM规范的字节码文件。
-
javac 是一种能够将Java源码编译为字节码的前端编译器。
-
javac 编译器在将Java源码编译为一个有效的字节码文件过程中经历了4个步骤,分别是词法解析、语法解析、语义解析以及生成字节码。
Oracle的JDK软件包括两部分内容:
-
一部分是将Java源代码编译成Java虚拟机的指令集的编译器。
-
另一部分是用于实现Java虚拟机的运行时环境。
Java的前端编译器
前端编译器 VS 后端编译器
- Java源代码的编译结果是字节码,那么肯定需要有一种编译器能够将Java源码编译为字节码,承当这个重要责任的就是配置在path环境变量中的javac编译器,javac 是一种能够将Java源码编译成字节码的前端编译器。
- HotSpot VM 中并没有强制要求前端编译器只能使用 javac 来编译字节码,其实只要编译结果符合JVM规范都可以被JVM所识别即可。在Java的前端编译器领域,除了javac之外,还有一种被大家经常使用的前端编译器,那就是内置在Eclipse中的ECJ(Eclipse Compiler for Java)编译器。和Javac的全量式编译不同,ECJ是一种增量式的编译器。
- 在Eclipse中,当开发人员编写完代码后,使用“Ctrl + S”快捷键时,ECJ 编译器所采取的编译方案是把未编译部分的源码逐行进行编译,而且每次都在全量编译。因此ECJ的编译效率会比javac更加迅速和有效,当然编译质量和 javac 相比大致还是一样的。
- ECJ 不仅是 Eclipse 的默认内置前端编译器,在Tomcat中同样也是使用 ECJ 编译器来编译jsp文件。由于ECJ编译器是采用GPV2的开源协议进行源代码公开,所有大家可以登录eclipse官网下载ECJ编译器的源码进行二次开发。
- 默认情况下,IDEA 使用 javac 编译器。(还可以设置为AspectJ编译器 ajc)
- 前端编译器并不会直接涉及编译优化等方面的技术,而是将这些具体优化细节移交给HotSpot的JIT编译器负责。
- 复习:AOP(静态提前编译器,Ahead Of Time Complier)
- class HelloWorld{ }
- 编译:javac HelloWorld.java
二、虚拟机的基石:Class文件
字节码文件里是什么?
源代码经过编译器之后便会生成一个字节码文件,字节码是一种二进制的类文件,它的内容是JVM 的指令,而不像c、c++ 经由编译器直接生成机器码。
什么是字节码指令(byte code)?
- Java虚拟机的指令是由一个字节长度的、代表着某种特定操作含义的操作码(opcode)以及跟随其后的零至多个代表此操作所需参数的操作数(operand)所构成,虚拟机中许多指令并不包含操作数,只有一个操作码。
- 比如:
-
如何解决供虚拟机解释执行的二进制字节码?
方式一:一个一个二进制的看,用Binary Viewer等工具。 -
方式二:使用javap指令:jdk自带的反解析工具。
-
方式三:使用IDEA插件:jclasslib 或 jclasslib bytecode viewer 客户端工具。(可视化更好)
三、Class文件结构
Class 类的本质:任何一个Class文件都对应着唯一 一个类或接口的定义信息,但反过来说,Class文件实际上并不一定以磁盘文件的形式存在,Class文件是一组以8位字节为基础单位的为二进制流。
Class文件格式:Class 的结构不像XML等描述语言,由于它没有任何分隔符号,所以在其中的数据项,无论是字节顺序还是数量,都是被严格限定的,哪个字节代表什么含义,长度是多少,先后顺序如何,都不允许改变。Class 文件格式采用一种类似于 C 语言结构体的的方式进行数据存储,这种结构只有两种数据类型:无符号数和表。
- 无符号数属于基本数据类型,以 u1、u2、u4、u8 来分别代表一个字节、2个字节、4个字节和8个字节的无符号数,无符号数可以用来描述数字、索引引用、数量值或者按照 UTF-8 编码构成字符串值。
- 表是由多个无符号数或者其他表作为数据项构成的复合数据类型,所有表都习惯性的以“_info"结尾。表用于描述有层次关系的复合结构的数据,整个Class文件本质上就是一张表。由于表没有固定长度,所以通常会在其前面加上个数说明。
换句话说,充分理解了每一个字节码文件的细节,自己也可以反编译出Java源文件来。
class文件结构概述:Class文件的结构并不是一成不变的,随着 Java 虚拟机的不断发展,总是不可避免的会对Class文件结构做出一些调整,但是其基本结构和框架是非常稳定的。
Class文件的总体结构如下:
-
魔数
-
Class文件版本
-
常量池
-
访问标识
-
类索引,父类索引,接口索引集合
-
字段表集合
-
方法表集合
-
属性表集合
-
ClassFile {
u4 magic;
u2 minor_version;
u2 major_version;
u2 constant_pool_count ;
cp_info constant_pool[constant_pool_count-1];
u2 access_flags;
u2 this_class;
u2 super_class;
u2 interfaces_count;
u2 interfaces[interfaces_count];
u2 fields_count;
field_info fields[fields_count];
u2 methods_count;
method_info methods[methods_count];
u2 attributes_count;
attribute_info attributes[attributes_count];
}
如下图所示:
下面的表格对上面的字段作了简单的解释:
这是一张Java字节码总的结构表,我们按照上面的顺序逐一进行解读就可以了。
下面的图片是对上面的字节码的简单标识。
3.1 魔数:Class文件的标志
Magic Number(魔数)
-
每个Class文件开头的4个字节的无符号整数称为魔数(Magic Number)。
-
它的唯一作用是确定这个文件是否为一个能被虚拟机接受的有效合法的Class文件,即:魔数是Class文件的标识符。
魔数值是固定为0xCAFEBABE,不会被改变
如果一个Class文件不以0xCAFEBABE开头,虚拟机在进行文件校验时就会直接抛出以下错误:
使用魔数而不是扩展名来进行识别主要是基于安全方面的考虑,因为文件扩展名可以随意地改动。
3.2 Class文件版本号
紧接着魔数的4个字节存储的是 Class 文件的版本号。同样也是4个字节。第5和第6个字节所代表的的含义就是编译的副版号 minor_version, 而第7个和第8个字节就是编译的主版本号 major_version。它们共同构成了class文件的格式版本号。譬如某个Class文件的主版本号为M,副版本号为m, 那么这个Class文件的格式版本号就确定为M.m 。
版本号和Java编译器的关系如下表:
Java的版本号是从45开始的,JDK 1.1之后的每一个JDK版本发布主版本号向上加1。
不同版本的Java编译器编译的Class文件对应的版本是不一样的。目前,高版本的Java虚拟机可以执行由低版本的编译器生成的Class文件,但是低版本的Java虚拟机不能执行由高版本编译器生成的Class文件。否则JVM会抛出java.lang.UnsupportedClassVerisonError
异常。
在实际应用中,由于开发环境和生产环境的不同,可能会导致该问题的发生,因此,需要我们在开发时,特别注意开发编译的JDK版本和生产环境中的JDK版本是否一致。
虚拟机JDK版本为1.K ( K >= 2 ) 时,对应的class文件格式版本号的范围为45.0 - 44+k.0 (含两端)。
3.3 常量池:存放所有常量
常量池是Class文件中内容最为丰富的区域之一,常量池对于 Class 文件中的字段和方法解析也有着至关重要的作用。随着Java虚拟机的的不断发展,常量池的内容也日渐丰富。可以说,常量池是整个Class文件的基石。
在版本号之后,紧跟着的是常量池的数量,以及若干个常量池表项。
在常量池中常量池的数据是不固定的,所以在常量池的入口需要放置一项u2类型的无符号数,代表常量池容量计数值(constant_pool_count)。与Java中语言习惯不一样的是,这个容量计数是从1而不是0开始的。
常量池计数器(constant_pool_count)
由于常量池的数量不固定,时长时短,所以需要放置两个字节来表示常量池容量计数值。常量池容量计数值(u2类型) : 从1开始,表示常量池中有多少项常量,即constant_pool_count=1 表示常量池中有0个常量项。
Demo的值为:
其值为0x0016,掐指一算,也就是22。需要注意的是,这实际上只有21项常量。索引为范围是1-21。为什么呢?
通常我们写代码时都是从0开始的,但是这里的常量池却是从1开始,因为它把第0项常量空出来了,这是为了满足后面某些指向常量池的索引值的数据在特定情况下需要表达“不引用任何一个常量池项目"的含义,这种情况可以用索引值0来表示。
int [] arr = new int[10]
常量池表
constant_pool 是一种表结构, 1~ constant_pool_count - 1
为索引,表明了后面有多少个常量项。常量池主要存放两大类常量:字面量(Literal)和符号引用(Symbolic References)。
它包含了class文件结构及其子结构中引用的所有字符串常量、类或接口名、字段名和其他常量。常量池中的每一项都具备相同的特征:第一个字节作为类型标记,用于确定该项的格式,这个字节称为 tag byte (标记字节、标签字节)。
字面量和符号引用在对这些常量解读前,我们需要搞清楚几个概念,常量池主要存放两大类常量:字面量(Literal)和符号引用(Symbolic References)。表如下:
String str = “at”;
final int num = 10;
全限定名:com/test/Demo
这个就是类的全限定名,仅仅是把包名的".“替换成了”/", 为了使连续的多个全限定名之间不产生混淆,在使用时最后一般会加入一个;
, 表示全限定名结束。
简单名称:是指没有类型和参数修饰的方法或者字段名称,比如类的add()
方法和num
字段的简单名称分别是add和num。
**描述符:**描述符的作用是用来描述字段的数据类型、方法的参数列表(包括数量、类型以及顺序)和返回值。根据描述符规则,基本数据类型(byte、char、double、float、int、long、short、boolean)以及代表无返回值的void类型都用一个大写字符来表示,而对象类型则用字符 L 加对象的全限定名来表示,见下表:
用描述符来描述方法时,按照先参数列表,后返回值的顺序描述,参数列表按照参数的严格顺序放在一组小括号“()”之内。
补充说明:虚拟机在加载class文件时才会进行动态链接,也就是说,Class文件中不会保存各个方法和字段的最终内存布局信息,因此,这些字段和方法引用不经过转换是无法直接被虚拟机使用的。当虚拟机运行时,需要从常量池中获得对应的符号引用,再在类的加载过程中的解析阶段将其替换为直接引用,并翻译到具体的内存地址中。
这里说明下符号引用和直接引用的区别与关联:
- 符号引用:符号引用以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标并不一定已经加载到了内存中。
- 直接引用:直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的,同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用,那说明引用的目标必定已存在于内存之中了。
总结一:
- 这14种表(或者常量项结构)的共同点是:表开始的第一位是一个u1类型的标志位(tar),代表当前这个常量项使用的是哪种表结构,即哪种常量类型。
- 在常量池列表中,CONSTANT_utf8_info常量项是一种使用改进过的UTF-8编码格式来存储诸如文字字符串、类或接口的全限定名、字段或者方法的简单名称以及描述符常量字符串信息。
- 这14种常量结构还有一个特点是,其中13个常量项占用的字节不固定,其大小由length决定。为什么呢?因为从常量池存放的内容可知,其存放的是字面量和符号引用,最终这些内容都会是一个字符串,这些字符串的大小是在编写程序时才确定的,比如,你定义一个类,类名可以取长取短,所以在没编译前,大小不固定,编译后,通过uft-8编码,就可以知道其长度。
总结二:
- 常量池:可以理解为Class文件之中的资源仓库,它是Class文件结构中与其他项目关联最多的数据类型(后面的很多数据类型都会指向此处),也是占用Class文件空间最大的数据项目之一。
- 常量池中为什么要包含这些内容:Java代码在进行Javac编译的时候,并不像 C 和 C++ 那样有“连接”这一步骤,而是在虚拟机加载Class文件的时候进行动态链接。也就是说,在Class 文件中不会保存各个方法、字段的最终内存布局信息,因此这些字段、方法的符号引用不经过运行期转换的话无法得到真正的内存入口地址,也就无法直接被虚拟机使用。当虚拟机运行时,**需要从常量池获得对应的符号引用,再在类创建时或运行时解析、翻译到具体的内存地址之中。**关于类的创建和动态链接的内容,在虚拟机类加载过程时再进行详细讲解。
3.4 访问标识
访问标识(access_flag)也叫访问标志、访问标记。
在常量池后,紧跟着访问标记,该标记使用两个字节表示,用于识别一些类或者接口层次的访问信息,包括:这个Class是类还是接口;是否定义为public
类型;是否定义为abstract
类型;如果是类的话,是否被声明为final
等,各种访问标记如下:
类的访问权限通常为ACC_开头的常量。每一种类型的表示都是通过设置访问标记的32位中的特定位来实现的。比如,若是public final 的类,则该标记为ACC_PUBLIC | ACC_FINAL。使用ACC_SUPER可以让更多的类更准确地定位到父类的方法super.method(),现代编译器都会设置并使用这个标记。
补充说明:
- 带有
ACC_INTERFACE
标志的class
文件表示的是接口而不是类,反之则表示的是类而不是接口。- 如果一个class文件被设置了
ACC_INTERFACE
标志,那么同时也得设置ACC_ABSTRACT
标志。同时它不能再设置ACC_FINAL
、ACC_SUPER
、ACC_ABSTRACT
这类互斥的标志除外,这两个标志不得同时设置。
- 如果一个class文件被设置了
ACC_SUPER
标志用于确定类或接口里面的incokespecial
指令使用的是哪一种执行语义。针对Java虚拟机指令集的编译器都应当设置这个标志。对于Java SE 8即后续版本来说,无论class文件中这个标志的实际值是什么,也不管class文件的版本号是多少,Java虚拟机都认为每个class文件均设置了ACC_SUPER标志。ACC_SUPER
标志是为了向后兼容由旧Java编译器所编译的代码而设计的。目前的ACC_SUPER标志由JDK 1.0.2之前的编译器所生成的access_flags中是没有确切含义的,如果设置了该标志,那么Oracle的Java虚拟机实现会将其忽略。
ACC_SYNTHETIC
标志意味着该类或接口是由编译器生成的,而不是由源代码生成的。- 注解类型必须设置
ACC_ANNOTION
标志。如果设置了ACC_ANNOTATION
标志,那么必须设置ACC_INTERFACE
标志。 ACC_ENUM
表明该类或其父类为枚举类型。
3.5 类索引、父类索引、接口索引集合
在访问标记后,会指定该类的类别、父类类别以及实现的接口,格式如下:
这三项数据来确定这个类的继承关系:
- 类索引用于确定这个类的全限定类名。
- 父类索引用于确定这个类的父类的全限定名,由于Java语言不允许多重继承,所以父类索引只有一个,除了java.lang.Object之外,所有的Java类都有父类,因此除了java.lang.Object外,所有Java类的父类索引都不为0。
- 接口索引集合就是用来描述这个类实现了哪些接口,这些被实现的接口将按 implements 语句(如果这个类本身是一个接口,则应当是extends语句)后的接口顺序从左到右排列在接口索引集合中。
this_class(类索引)
- 2字节无符号整数,指向常量池的索引。它提供了类的全限定名,如
com/java1/Demo
。this_class的值必须是对常量池表中某项的一个有效索引值。常量池在这个索引处的成员必须为CONSTANT_Class_info类型结构体,该结构体表示这个class文件所定义的类或接口。
super_class(父类索引)
- 2字节无符号整数,指向常量池的索引。它提供了当前类的父类的全限定名。如果我们没有继承任何类,其默认继承的是java/lang/Object类,同时由于Java不支持多继承,所以其父类只有一个。
- superclass指向的父类不能是final。
interfaces
- 指向常量池索引集合,它提供了一个符号引用到所有已实现的接口。
- 由于一个类可以实现多个接口,因此需要以数组的形式保存多个接口的索引,表示接口的索引也是一个指向常量池的 CONSTANT_Class(当然这里就必须是接口,而不是类)。
interfaces_count(接口计数器)
- interface_count项的值表示当前类或接口的直接超接口数量。
**interfaces [] (**接口索引集合)
- interfaces [] 中每个成员的值必须是对常量池中某项的有效索引,它的长度为interface_count。每个成员interfaces[i] 必须为CONSTANT_Class_info 结构,其中 0 <= i < interfaces_count。在 interfaces[] 中,各成员所表示的接口顺序和对应的源代码中给定的接口顺序(从左至右)一样,即 interfaces[0] 对应的是源代码中最左边的接口。
3.6 字段表集合
fields:用于描述接口或类中声明的变量。字段(field)包括类级变量以及实例变量,但是不包括方法内部、代码块内部声明的局部变量,(local variables)。段叫什么名字、字段被定义为什么数据类型,这些都是无法固定的,只能引用常量池中的常量来描述。它指向常量池索引集合,它描述了每个字段的完整信息。比如字段的标识符、访问修饰符(public、private、或protected)、是类变量还是实例变量(static修饰符)、是否是常量(final修饰符)等。
注意事项:
字段表集合中不会列出从父类或者实现的接口中继承而来的字段,但是可能列出原本Java代码之中不存在的字段。譬如在内部类中为了保持对外部类的访问性,会自动添加指向外部类的访问性,会自动添加指向外部类实例的字段。
在Java语言中字段是无法重载的,两个字段的数据类型、修饰符不管是否相同,都必须使用不一样的名称,但是对于字节码来讲,如果两个字段的描述符不一致,那字段重名就是合法的。
fields_count (字段计数器):field_count的值表示当前class文件fields表的成员个数,使用两个字节表示。fields表中的每个成员变量都是一个field_info结构,用于表示该类或接口所声明的所有类字段或者实例字段,不包括方法内部声明的变量,也不包括从父类或父类接口继承的那些字段。
fields [] (字段表):fields表中的每个成员都必须是一个fields_info 结构的数据项,用于表示当前类或接口中某个字段的完整描述。
一个字段的信息包括如下信息。这些信息中,各个修饰符都是布尔值,要么有,要么没有。
- 作用域(public、private、protected修饰符)
- 是实例变量还是类变量(static修饰符)
- 可变性(final)
- 并发可见性(volatile修饰符,是否强制从主内存读写)
- 可否序列化(transient修饰符)
- 字段数据类型(基本数据类型、对象、数组)
- 字段名称
字段表结构:字段表作为一个表,同样有他自己的结构:
-
字段表访问标识:我们知道,一个字段可以被各种关键字区修饰,比如:作用域修饰符(public、private、protected)、static修饰符、final修饰符、volatile修饰符等等。因此,其可像类的访问标志那样,使用一些标志来标记字段。字段的访问标志有如下这些:
标志名称 标志值 含义 ACC_PUBLIC 0x0001 字段是否为public ACC_PRIVATE 0x0002 字段是否为private ACC_PROTECTED 0x0004 字段是否为protected ACC_STATIC 0x0008 字段是否为static ACC_FINAL 0x0010 字段是否为final ACC_VOLATILE 0x0040 字段是否为volatile ACC_TRANSTENT 0x0080 字段是否为transient ACC_SYNCHETIC 0x1000 字段是否为编译器自动产生 ACC_ENUM 0x4000 字段是否为enum -
字段名索引:根据字段名索引的值,查询常量池中的指定索引项即可。
-
描述符索引:描述符的作用是用来描述字段的数据类型、方法的参数列表(包括数量、类型以及顺序)和返回值,根据描述符规则,基本数据类型(byte,char,double,float,int,long,short,boolean)以及代表无返回值的 void 类型都用一个大写字符来表示,而对象则用字符 L 加对象的全限定名来表示,如下所示:
字符 类型 含义 B byte 有符号字节型数 C char Unicode字符,UTF-16编码 D double 双精度浮点数 F float 单精度浮点数 I int 整形数 J long 长整数 S short 有符号短整数 Z boolean 布尔值true/false L Classname reference 一个名为Classname的实例 [ reference 一个一维数组 -
属性表集合:一个字段还可能拥有一些属性,用于存储更多的额外信息。比如初始化值、一些注释信息等。属性个数存放在attribute_count中,属性具体内容存放在attributes数组中。
以常量属性为例,结构为:
ConstantValue_attribute { u2 attribute_name_index; u4 attribute_length; u2 constantvalue_index; }
说明:对于常量属性而言:attribute_length的值恒为 2
3.7 方法表集合
methods: 指向常量池索引集合,它完整描述了每个方法的签名。在字节码文件中,每个method_info项都对应着一个类或者接口中的方法信息。比如方法的访问修饰符(public、private或protected),方法的返回值类型以及方法的参数信息等。
如果这个方法不是抽象的或者不是native的,那么字节码中会体现出来。
一方面,methods表只描述当前类或接口中声明的方法,不包括从父类或父接口继承的方法。另一方面,methods表有可能会出现由编译器自动添加的方法,最典型的便是编译器产生的方法信息(比如:类(接口)初始化方法< clinit >()和实例初始化方法< init >())。
使用注意事项:在JAVA语言中,要重载(Overload)一个方法,除了要与原方法具有相同的简单名称之外,还要求必须拥有一个与原方法不同的特征签名,特征签名就是一个方法中各个参数在常量池中的字段符号引用的集合,也就是因为返回值不会包含在特征签名之中,因此Java语言里无法仅仅依靠返回值的不同来对一个已有方法进行重载。但是class文件格式中,特征签名的范围更大一些,只要描述符不是完全一致的两个方法就可以共存。也就是说,如果两个方法有相同的方法和特征签名,但返回值不同,那么也是可以合法共存于同一个class文件中。
也就是说,尽管java语法规范并不允许在一个类或接口中声明多个方法签名相同的方法,但是和Java语法规范相反,字节码文件中恰恰运行存放多个方法签名相同的方法,唯一的条件就是这些方法之间的返回值不能相同。
-
methods_count(方法计数器):methods_count的值表示当前class文件methods表的成员个数,使用两个字节来表示。methods 表中每个成员都是一个 method_info 结构。
-
method [ ] (方法表):methods表中的每个成员都必须是一个method_info结构,用于表示当前类或接口中某个方法的完整描述。如果某个method_info结构的access_flags项既没有这是ACC_NATIVE标志也没有设置ACC_ABSTRACT标志,那么该结构中也应该包含实现这个方法所用的Java虚拟机指令。method_info 结构可以表示类和接口中定义的所有方法,包括实例方法、类方法、实例初始化方法和类或接口初始化方法。方法表的结构实际与字段表是一样的,方法表的结构如下:
类型 名称 含义 数量 u2 access_flags 访问标志 1 u2 name_index 方法名索引 1 u2 descriptor_index 描述符索引 1 u2 attributes_count 属性计数器 1 attribute_info attributes 属性集合 attributes_count
3.8 属性表集合(attributes)
方法表集合之后的属性表集合,指的是class文件所携带的辅助信息,比如该class文件的源文件的名称。以及任何带有RetentionPolicy.CLASS或者RetentionPolicy.TUNTIME的注解。这类信息通常被用于Java虚拟机的验证和运行,以及Java程序的调试,一般无需深入了解。此外,字段、方法表都可以有自己的属性表。用于描述某些场景专有的信息。
属性表集合的限制没有那么严格,不在要求各个属性表具有严格的顺序,并且只要不与已有的属性名重复,任何人实现的编译器都可以向属性表中写入自己定义的属性信息,但Java虚拟机运行时会忽略掉它不认识的属性。
- attributes_count(属性计数器):attributes_count的值表示当前class文件属性表的成员个数,属性表中每一项都是一个attribute_info结构。
- attributes [ ] (属性表):属性表的每个项的值必须是attribute_info结构,属性表的结构比较灵活,各种不同的属性只要满足以下结构即可。
属性的通用格式
类型 | 名称 | 数量 | 含义 |
---|---|---|---|
u2 | attribute_name_index | 1 | 属性名索引 |
u4 | attribute_length | 1 | 属性长度 |
u1 | info | attribute_length | 属性表 |
即只需说明属性的名称以及占用位数的长度即可,属性表具体的结构可以,属性表具体的结构可以去自定义。
属性类型:属性表实际上可以有很多种类型,上面看到的 Code 属性只是其中一种,Java8里面定义了23种属性。
四、小结
随着Java平台的不断发展,在将来,Class文件的内容也一定会做进一步的扩充,但是其基本的结构不会做重大调整。从Java虚拟机的角度看,通过Class文件,可以让更多的计算机语言支持Java虚拟机平台。因此,Class文件结构不仅仅是从Java虚拟机的执行入口,更是Java生态圈的基础和核心。