如何在定位较旧的JDK版本时避免使用NoClassDefFoundErrors和NoSuchMethodErrors?

时间:2012-09-22 00:54:23

标签: java compilation backwards-compatibility

假设我想编写一个针对某些JRE版本的应用程序(例如1.6),但是在我用来开发它的机器上,安装了更新版本的JRE(例如1.7)。

天真的方法是将编译器级别设置为1.6(我使用Eclipse,但这可能不是很重要,因为问题很普遍)。但是,这还不够。设置编译器的源级别可确保源文件仅使用该Java版本可用的语言功能,因此生成的类文件具有正确的次要版本,因此目标JVM将能够加载和运行它们。

但是还有另一个更微妙的问题:如果我在1.7中添加的代码中使用类或方法并尝试在安装了1.6运行时的机器上运行应用程序,则会失败,并显示{{1} }或NoClassDefFoundError

问题是同一个程序在dev机器上运行正常,因为安装在它上面的1.7 JDK确实包含这些类。编译器或IDE也不会抱怨。我引用的类和方法的唯一指标是JavaDoc中的NoSuchMethodError注释。

那么如何确保我从不使用旧版JRE中不可用的类或方法?唯一可靠的解决方案是始终在构建路径上具有确切的目标JRE版本吗?这意味着我需要在我的开发机器上为每个这样的情况安装一个额外的JDK(1.7,1.6,可能是1.5,甚至可能是1.4)。

1 个答案:

答案 0 :(得分:3)

在编译期间使用指向1.6 JRE(特别是bootcpasspath)的rt.jar选项。这样做将强制检查所提供的所有类,方法和属性是否实际存在于提供的rt.jar中。

有关详细信息,请参阅javac - cross-compilation options