将应用程序迁移到 Java 7 的动机和动力

java migration java-7

2022-09-02 22:14:33

Java 7已经存在了一段时间。现在，如果要将应用程序迁移到Java 7而不进行任何更改（代码/配置），是否有任何固有的优点或缺点？我很想知道在这种迁移过程中会遇到什么问题。

编辑：通过迁移，我的意思是代码将保持不变，但运行时将更改为Java 7正如我所提到的没有代码/配置更改，所以我认为应该影响应用程序的事情是新的编译器/ VM级默认优化。因此，我一直在寻找任何会影响整体应用程序行为的东西。

答案 1

目前我发现我的应用程序（最初是用Java 7编写的）的明显缺点是大多数人没有7，并且需要一些努力才能获得它。在撰写本文时，默认的Java下载页面仍然指向Java 6，而不是7，并且大多数当前的Linux发行版似乎也默认安装了6。Ubuntu 11.10是第一个在其存储库中拥有Java的。

同样在Ubuntu方面，我注意到的一件事是，即使安装了Java 7，我还没有找到一种干净的方式来检查它是否是默认值（再说一遍，很可能它不是）。我只是使用一个shell脚本来解析输出并适当地启动它。update-alternatives --query java

这是我有意识地决定使用7，因为它中有许多新功能，我可以利用它，当该应用程序实际上达到我认为它脱离alpha / beta的地步时，我希望Java 7无论如何都会获得更多的立足点！

这些优势几乎都集中在使用添加的功能上 - 我发现使用资源构建的尝试使使用IO的东西使我的许多代码更容易阅读（不再嵌套尝试/最终的内在尝试/捕获），并且我也使用了一些额外的API，如filewatcher API。我也非常喜欢JComboBox和底层模型现在是通用的，这节省了Swing应用程序中相当多的投射。

简而言之，如果你不打算利用Java 7的任何功能，而你只是在升级它，那么在Java 7至少变得更加成熟之前，几乎没有动力这样做。它使我的代码更加干净，并且对一些额外的库很有帮助，但它也引起了一些麻烦。

答案 2

我还会考虑在java 6或更低版本运行新代码（java 7）的概率/需求变化，因为某些功能不会像下面这样编译：

开关语句中的字符串
使用资源试用语句
改进了用于创建通用实例的类型推断（“菱形运算符”）
改进的异常处理（多捕获）

在切换之前，请确保在考虑的项目上使用的 java 版本不太可能被强制执行。