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

Question

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

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

Answer 1

目前，我发现我的应用程序(最初是用Java 7编写的)的一个明显的缺点是大多数人没有7，需要付出一点努力才能得到它。在编写本报告时，默认的Java下载页面仍然指向Java6，而不是7，而且大多数当前的Linux发行版在默认情况下似乎也安装了6。Ubuntu11.10甚至是第一个在其存储库中使用Java的用户。

另外，在Ubuntu方面，我注意到的一件事是，即使安装了Java7，我还没有找到一种干净的方法来检查它是否是默认的 (而且也有可能没有安装)。我只是使用一个shell脚本来解析来自update-alternatives --query java的输出并适当地启动它。

这是我有意识地决定使用7，因为它有许多新的特性，我可以利用它，到了说的时候，应用程序实际上达到了我认为它脱离alpha / beta的地步，我希望Java 7在任何时候都能获得更多的立足点！

优点主要集中在使用添加的特性--我发现使用IO组件的try with resources构造使我的代码更容易阅读(不再有嵌套的try / inside‘s IO try / catches)，而且我还使用了一些额外的API，比如filewatcher API。我也很喜欢JComboBox和底层模型现在是通用的，这节省了一些在Swing应用程序中的转换。

总之，如果您不打算真正利用Java 7的任何特性，而您只是在升级Java 7，那么在Java 7至少变得更加成熟之前，没有什么动机这样做。它使我的代码更加简洁，并且对一些额外的库很有帮助，但也引起了一些麻烦。

Answer 2

我还将考虑在java 6或更少中运行新代码(Java 7)的可能性/需求变化，因为有些特性不会像下面这样编译：

• 开关语句中的字符串
• 尝试-with-resources语句
• 改进的泛型实例创建类型推断(“菱形操作符”)
• 改进的异常处理(多捕获)

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

Answer 3

问题是“什么时候”，而不是“如果”。如果您迫切需要一些新的Java 7特性(值得怀疑)，那么这是显而易见的。

否则，在认真考虑迁移生产和UAT环境之前，我会亲自等待大约一年左右的时间来排除任何其他可能的显示中断&头疼的问题。

不过，您应该已经有了一个运行Java 7的环境，以便了解您将从事的工作。Java 6将在某个时候退役，您应该已经做好了充分的准备来进行转换。