我有一个场景，我针对库的版本 1 编写了代码，但我想发布库的版本 2。代码已发货，因此不可更改。我担心它可能会尝试访问存在于 v1 中但已在 v2 中删除的类或库成员。
我想可以编写一个工具来做一个简单的检查，看看代码是否会链接到更新版本的库。我很欣赏即使代码链接，代码仍然可能非常破碎。我正在从另一边考虑这个问题——如果代码无法链接，那么我可以确定存在问题。
据我所知，我需要通过字节码检查引用、方法调用和对库类的字段访问，然后使用反射来检查类/成员是否存在。
我有三个问题：
(1)这样的工具是否已经存在？
(2)我有一种琐碎的感觉，它比我想象的要复杂得多，而且我错过了一些重要的事情——是这样吗？
(3)你知道一个方便的库，它可以让我检查字节码，以便我可以找到方法调用、引用等？
谢谢！
更改 IDE 中的库将导致所有可能的编译时错误。
您不需要其他任何东西，除非您的代码使用另一个库，而后者又使用更新的库。
我认为Clirr - 一个二进制兼容性检查器 - 可以在这里提供帮助：
Clirr 是一个检查 Java 库与旧版本的二进制和源代码兼容性的工具。基本上你给它两组 jar 文件，Clirr 会转储出公共 api 中的更改列表。Clirr Ant 任务可以配置为在检测到不兼容的 api 更改时中断构建。在持续集成过程中，Clirr 可以自动防止意外引入二进制或源代码兼容性问题。
特别要注意 Spring 配置文件。类名配置为文本，直到运行时才会显示为缺失。
如果您有权访问源代码，则可以针对新库编译源代码。如果它不编译，你肯定有问题。如果它编译了，如果程序使用反射、某种 IoC 东西（如 Spring 等），你可能仍然会遇到问题。
如果您有单元测试，那么您可能会有更好的更改来捕获任何链接错误。
如果您只有程序的 .class 文件，那么除了将类文件反编译为源代码并针对新库再次编译源代码之外，我不知道有任何工具可以提供帮助，但这听起来不太健康。
您提到的检查是由 JVM/Java 类加载器完成的，请参见例如Linking of Classes and Interfaces。
所以“尝试链接”可以通过尝试运行应用程序来简单地实现。当然，您可以自行对 .class/.jar 文件集合进行检查以运行它们。我猜像BCEL这样的第三方字节码操纵器也会为你做类似的检查。
我注意到您在标签中提到了反射。如果您通过反射加载类/调用方法，则通常无法对此进行分析。
祝你好运！