这两天在研究字节码格式..发现一个很有趣的问题.属性表中的属性,之间的区别竟然不是通过类似标志位的形式,而是通过常量池指向utf8的字符串匹配..
    比如我如何判断是ConstantValue类型的属性,是在属性开始的atrribute_name_index指向了常量池中的 字符串 ConstantValue.这样就表示这个是ConstantValue类型的属性..

    我承认我没查过具体的相关源码,只是通过自己试验得出的上面这个非常残酷的结论.所以希望得到指正.谢谢..

    推理过程如下

分析源码

public final class Test {
    final float b = 1.2f;
    final int c = 1;
}

对应的常量池

Constant pool:
   #1 = Methodref          #6.#19         //  java/lang/Object."<init>":()V
   #2 = Float              1.2f
   #3 = Fieldref           #5.#20         //  Test.b:F
   #4 = Fieldref           #5.#21         //  Test.c:I
   #5 = Class              #22            //  Test
   #6 = Class              #23            //  java/lang/Object
   #7 = Utf8               b
   #8 = Utf8               F
   #9 = Utf8               ConstantValue
  #10 = Utf8               c
  #11 = Utf8               I
  #12 = Integer            1
  #13 = Utf8               <init>
  #14 = Utf8               ()V
  #15 = Utf8               Code
  #16 = Utf8               LineNumberTable
  #17 = Utf8               SourceFile
  #18 = Utf8               Test.java
  #19 = NameAndType        #13:#14        //  "<init>":()V
  #20 = NameAndType        #7:#8          //  b:F
  #21 = NameAndType        #10:#11        //  c:I
  #22 = Utf8               Test
  #23 = Utf8               java/lang/Object

对应的字节码
第一个属性是00100007000800010009000000020002
第二个属性是0010000A000B0001000900000002000C

中间的attribute_name_index 都是指向#0009 也就是  #9 = Utf8              ConstantValue


最后吐槽下,怎么传图片啊啊啊啊

就是字符串匹配没错。这没啥残酷的吧。
当初这样设计是为了后面能更方便的扩展Class文件格式，能够添加新的属性类型而不需要改变Class文件格式的基本设计。使用标志位（flag）的形式每次在添加新属性类型时就得改变这个flag的允许值的定义，颇麻烦。

另外，Class文件里是允许包含JVM规范里未定义的属性的，JVM实现在处理这样的属性时允许忽略掉它们。例如说，我们可以自己在Class文件里嵌个签名啥的，用自定义属性包起来，这样JVM会无视它所以能正常运行，而别人假如直接拿了这个Class文件去用我们也可以发现。类似这样。


ItEye的群组里的论坛貌似就是发不了附件的所以不能直接传图片，而得传到群共享里然后自己在帖里用img标签链过来。

谢谢撒迦..