为何Show Bytecode与反编译后的Class文件内容存在差异？

这个差异确实是因为两个功能的处理逻辑、目标定位完全不同导致的，具体拆解如下：

1. Show Bytecode：字节码的“可读性翻译” #

Show Bytecode的核心是把Class文件里的原始字节码（十六进制指令）转换成人类能读懂的JVM指令助记符，它的目标是尽可能还原字节码的原始结构和细节，不会做任何“简化”或“逆向成Java语法”的操作：

• 对于枚举类，它会展示编译器自动生成的所有细节：比如构造方法会带上编译器隐式添加的int ordinal（枚举常量的序号）和String name（枚举常量的名称）参数，签名会变成Fruit(java.lang.String, int, java.lang.String)；
• 会显示静态代码块里枚举常量的初始化逻辑、自动生成的values()和valueOf()方法的完整字节码实现；
• 所有JVM层面的指令（比如aload_0、invokespecial、putstatic）都会原原本本地展示出来，方便你理解JVM实际执行的步骤。

举个字节码里构造方法的片段示例：

// Show Bytecode里的构造方法片段
Fruit(java.lang.String, int, java.lang.String);
    Code:
       0: aload_0
       1: aload_2
       2: iload_1
       3: invokespecial #1                  // Method java/lang/Enum."<init>":(Ljava/lang/String;I)V
       6: aload_0
       7: aload_3
       8: putfield      #2                  // Field color:Ljava/lang/String;
      11: return

2. FernFlower：字节码的“逆向工程还原” #

FernFlower是专门的Java反编译器，它的目标是把字节码转换成符合Java语法规范、接近原始手写代码的可读源码，会主动隐藏编译器生成的冗余或底层细节：

• 对于枚举类，它会把编译器自动添加的ordinal、name参数和相关初始化逻辑隐藏，只展示你手写的构造方法签名（比如Fruit(String color)）；
• 会把静态代码块里的枚举常量初始化逻辑还原成你熟悉的APPLE("red"), BANANA("yellow")形式；
• 自动生成的values()、valueOf()方法会被简化成Java枚举类的默认形式，不会展示具体的字节码实现；
• 还会做语法优化，比如把字节码里的分支指令转换成Java的if/switch，把合成类、合成方法隐藏，让代码看起来和你一开始写的几乎一致。

反编译后的示例代码：

public enum Fruit {
    APPLE("red"),
    BANANA("yellow");

    private final String color;

    private Fruit(String color) {
        this.color = color;
    }
}

总结 #

两者的定位从根本上不同：

• Show Bytecode是给开发者看JVM执行的底层细节，追求的是字节码层面的准确性，不会做任何语法层面的简化；
• FernFlower是给开发者看接近原始手写的Java代码，追求的是可读性，会主动过滤掉编译器生成的底层冗余内容。

这就是为什么同一个枚举类的Class文件，经过两个工具处理后结果完全不一样。

内容的提问来源于stack exchange，提问作者Person239183218930