如何检测Java中编译期常量替换后的公共静态final字段依赖？

当你用javac编译包含public static final基本类型或字符串常量的代码时，编译器会把常量值直接内联到调用类的字节码里——就像你例子里B类的A.AA会被替换成1。这导致调用类的字节码里完全没有对A类的符号引用，像jdeps这种靠字节码符号分析的工具自然识别不出B依赖A。要获取这类依赖信息，有几个可行的方向：

一、直接分析源代码 #

既然字节码已经丢失了依赖信息，那就回到源代码层面找依赖：

• 用静态代码分析工具，比如Checkstyle、PMD，或者JDepend的源码分析模式，这类工具会直接扫描源代码里的引用，能准确识别B对A的常量引用。
• 自己写个简单的脚本，用Java Compiler API或者ANTLR解析语法树，找出所有对static final字段的引用，记录对应的类依赖。

二、编译时做干预，保留字节码里的依赖痕迹 #

通过调整编译方式，让javac不内联常量，或者保留对原类的引用：

1. 修改常量定义，避免成为编译期常量
   把常量的初始值改成编译期无法直接计算的表达式，比如：

   // A.java
   public class A {
       // 用Integer.valueOf包装，让javac没法在编译期确定值，也就不会内联
       public static final int AA = Integer.valueOf(1);
   }
   

   这样编译后，B类的字节码会保留对A.AA的符号引用，jdeps就能正常识别依赖。

2. 用javac非标准参数禁用常量内联
   使用-XDdisableFinalConstantInlining这个javac非标准选项（注意不同JDK版本可能有差异），强制编译器不内联static final常量：

   javac -XDdisableFinalConstantInlining A.java B.java
   

   编译后B类的字节码会保留对A类的引用，jdeps可以直接检测到依赖关系。

三、针对已编译字节码的补救方法 #

如果已经拿到了内联后的字节码，也可以试试这些方法：

• 对比字节码里的常量值和已知类的static final字段，匹配可能的依赖（这种方法准确性不高，适合小范围场景）。
• 用JD-GUI、Fernflower这类反编译工具把B类反编译，看反编译后的代码里有没有对A类常量的引用，再手动关联依赖。

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