正如我已经提到的,即使在其如何以及何时废弃API中,关于实际删除已弃用的API 的策略也没有任何说明......
基于旧JVM(例如1.4)的应用程序数量仍然很重要,部分原因是应用程序服务器需要很长时间才能使用新版本的JVM验证自己...
实际在生产中运行的应用程序数量绝对意味着这种"向后兼容"策略可能不会很快被破坏.
正如我已经提到的,即使在其如何以及何时废弃API中,关于实际删除已弃用的API 的策略也没有任何说明......
基于旧JVM(例如1.4)的应用程序数量仍然很重要,部分原因是应用程序服务器需要很长时间才能使用新版本的JVM验证自己...
实际在生产中运行的应用程序数量绝对意味着这种"向后兼容"策略可能不会很快被破坏.
有几种类型的向后兼容性:
旧的源代码可以用新的编译器编译吗？
这可以通过将旧构造转换为新构造的工具来处理,或者使用类似"源1.6"的工具来处理.指令位于文件顶部.
旧类文件可以在新的JVM中运行吗？
在我的世界里,这是一个完整的节目.我们使用如此多的第三方库来强制同时升级所有这些库会成本太高.
这也是不删除已弃用的类和方法的驱动因素,但程度较轻.
旧类文件可以调用使用新编译器编译的代码吗？
由于回调,这是#2的重要部分.
新编译的代码可以从旧类文件中调用代码吗？
#2的另一个重要部分.
代码看起来与开发人员大致相似吗？
这对于培训和处理尚未完全转换的大型代码库非常重要.更微妙的方面是在混合代码库中可以使用多少新功能.如果你打破这个太远,你就会得到类似Scala而不是Java ++的东西.
添加泛型是为了保留所有这些类型的兼容性.我认为对Java的任何不兼容的更改都必须保留至少2,3和4才有可能被Java接受.处理#1的工具也是最低要求.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
