标签：java compilation backwards-compatibility

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

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

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

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

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

解决方法:

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

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

标签：java,compilation,backwards-compatibility
来源： https://codeday.me/bug/20190630/1331558.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。