如何证明从Java 6迁移到Java 7的合理性？

28

我们正在从Java 6迁移到Java 7。该项目落后于进度，有被放弃的风险，在这种情况下，它将继续使用Java 6。

Java 7有哪些具体改进，我们可以与我们的经理一起使用，并说服他使用JDK 7是重要的？寻找我可以在Oracle Java 7（相对于Java 6）中突出显示的错误修复程序。就我而言，在安全性，性能，Java 2D /打印等方面的修复将更加畅销。例如，编译器修复不会有太大用处。

[我正在浏览许多站点，例如Oracle采用指南，错误数据库，有关Stack Overflow的问题 ]。

更新：感谢您的回答。我们将更新重新计划为下一个版本。我们最接近的是安全性。接受投票最高的答案。

java migration

— 贾扬
source

5

你真幸运从仍然经常在Stack Overflow上弹出的问题来看，有些人仍然对Java 1.4（该平台已有11年的历史了！）感到困惑。

— Joachim Sauer

3

如果您不了解7中所需的某些功能，为什么现在要进行升级？也许您在浪费时间，应该多考虑是否应该证明其合理性，而不是应该如何证明其合理性。

— 布莱恩·奥克利

1

是我还是标题倒退？

— Radu Murzea

1

更大的问题是：您为什么要进行如此艰难的升级？我能够在一周内将一百万个loc项目升级到Java7。我认为，解决您的问题的原因是分析您为何如此费劲地进行升级。

— Andrew T

2

// @安德鲁·芬内尔：对不起。我认为没有那么重要。实际的移植在不到一周的时间内就完成了。主要是由于我们使用了sun专有的api。这是一个受功能特定的兼容性影响的代码，而不是实际的代码行数（约400万行）。造成延迟的原因是各种因素，例如工具支持，例如使用cobertura 2.0的代码覆盖率。只是在稳定。另一个工具是Rational Functional Tester，它需要升级（我们选择不升级）。也许我会写一篇有关影响工作的总体因素的说明

— 。– Jayan

44

Java 6已于今年2月到达EOL，除非您购买了非常昂贵的企业支持，否则Java 6 将不再接收公共更新（包括安全性）。

那应该是所有需要的理由。

此外，大量证据表明Java运行时的向后兼容性非常好。您可能只需要用Java 7替换Java 6安装，所有应用程序都将继续正常运行而不会出现任何问题。当然，这不能保证，建议进行大量测试以确认确实没有问题。

— 迈克尔·博格沃特
source

2

那应该是一个可以接受的答案。事实证明，基于EOL日期的推理对我而言最适合需要特定产品更新的理由，尤其是Java。为了完成论证，我还将添加关于向后二进制兼容性的注释（最好以一些正式的Oracle语句作为备份），以及关于需要对更新进行烟雾测试的注释（例如，对于对版本“应用程序配置中的“ 6”）

— gnat 2013年

1

这基本上是大多数公司升级的唯一原因。

— jwenting

迈克尔，在您的答案中添加我提到的注释（兼容性和烟雾测试的说明）是否有意义？为了完整起见，可以这么说

— 蚊蚋

1

@gnat：完成了，尽管我怀疑反对迁移的人们是否需要被告知测试的必要性，而不仅仅是烟雾测试。有时肯定存在严重的不兼容性。

— Michael Borgwardt

@MichaelBorgwardt很好，讲述这一点有些棘手，而且与引人注目而不是技术上的正确有关。当有人“反对改变”时，我就清楚而清晰地陈述了类似的东西，这是我学到的一种相当困难的方法。这种把它们发送信号，“我们倾听和分享您的问题，我们不用太担心”，让他们感到受重视（而不是忽略）......并最终导致变化的:)更容易批准

— 蚊蚋

29

通常，有许多相当广泛的更改可以使程序员更轻松地进行操作。您的经理可能不太在意这些事情，但是可以使程序员花更少的时间来考虑样板代码，从而有更多的时间来考虑他们正在实现的目标，从而提高效率，减少错误等。这可能是一个非常有力的论据。Oracle有相当广泛的更改列表，但是它相当冗长，因此我将尽可能总结一下。

语言功能包括：

泛型上的样板更少。该代码Map<String, String> myMap = new HashMap<String, String>();可以简化为Map<String, String> myMap = new HashMap<>()。编译器可以从左侧推断出右侧所需的Generic类型，因此您的代码将变得更短，更快速。
字符串现在在switch语句中工作，使用.equals()方法的语义代替==。
使用try-with-resources进行自动资源管理。这使代码更整洁，但与旧式的基于try / final的代码相比也具有优势。如果在try语句中引发了一个异常，然后在关闭时引发了另一个异常，则使用传统try / finally语句的代码将完全丢失原始异常，并且只传递在finally块中引发的异常。在try-with-resources语句中，运行时将抑制close（）调用引发的异常，并在堆栈中冒泡原始异常，并假定该原始异常是第一个导致所有问题的那个地点。此外，通过禁止删除，而不是将其他异常抛弃到垃圾收集器，可以使用来检索抛出异常的异常Throwable.getSuppressed。
可以使数字文字更易于阅读。所有数字文字都允许使用下划线，因此int n = 1000000000可以使诸如此类的内容更具可读性int n = 1_000_000_000，将其解析为十亿则更容易，并且更容易在不注意的情况下错误输入。另外，二进制文字可以以形式使用0b10110101，使与位域一起工作的代码更易于阅读。
可以在同一catch语句中处理多种异常类型，从而减少了重复的代码，并可能使以后的重构更加容易。

这些更改中的每一项都是您的经理可能不会直接关心的，但是它们使编写正确的代码变得更加容易，而无需付出太多的努力和思想，这使您可以将精力集中在正在尝试的实际逻辑上实施，它们也使以后阅读代码变得容易一些，从而使调试更快。

在API方面，还发生了许多API更新：

在安全方面，随着加密技术的不断发展，已添加/弃用了多种加密方法。
文件IO已更改（尽管这可能是更好的链接），但在许多地方都增加了一些更好的抽象。我还没有亲自研究过新的IO内容，但是它看起来像是一个非常有用的全面检查，使文件系统的工作变得更加轻松而又没有太多麻烦。
Unicode支持最高为Unicode 6.0，以及许多其他国际化增强功能。
您在问题中提到的Java2D已得到改进。更好的Linux字体支持，现代机器上更好的X11渲染以及对藏文脚本的处理。

— 比利·梅尔曼
source

1

Nit选择：实际上，字符串开关“就像在使用String.equals方法一样”运行（来自链接到的文档）。实际上，String.equals只要最终效果相同，编译器就可以自由地进行优化，以便不使用它。（而且，我希望它会String.hashcode在一定数量的转换案例之上使用。）

— Stephen C

足够真实。大多数编译器被允许做吨的优化不会改变，虽然语义，所以它经常有多余的指出这样的小事; 我只特别提到了.equals（），以明确表示这种情况不会被忽略。尽管如此，我还是更新了措辞。

— Billy Mailman

不建议使用字符串开关，因为您要打开未绑定的域。在这里打开Enums是一个典型的中间立场，因为您可以使用String这样的表示形式，但是具有语义。哦，+ 1表示完整答案。

— Martijn Verburg

在switch语句中使用字符串而不是整数常量的优点是什么？

— Giorgio

3

其中唯一的业务原因可能是安全性增强。技术细节对商人来说是有争议的，而且是完全无关紧要的。

— jwenting

8

try-with-resources是一项值得单独升级到Java 7的功能。资源泄漏/内存泄漏是Java开发中的重大风险，而TWR则大大降低了这种风险。

我要补充一点，如果您的应用程序具有文件/网络I / O功能，那么新的NIO.2文件抽象和异步功能也值得一提。

— 马丁·弗伯格（Martijn Verburg）
source

他们还减少了所需的PermGen数量，并改用了Heap或本机内存，我不确定现在将其存储在何处。这意味着通过Java 8，您不需要设置两个最大内存参数。

— Andrew T Finnell

try-with-resources是否与try-finally相同，但样板更少？

— jhewlett

1

我认为这样的想法是减少样板意味着更容易正确。

— MatrixFrog

1

减少样板，并纠正关闭技巧。他们发现在 OpenJDK中大约有2/3的时间他们在手动执行错误操作。...我怀疑其他代码集中的错误率很高。

— Martijn Verburg

6

可能有一个原因，您不应该这样做切换到Java 7：如果你要使用Oracle的VM和软件无论是在嵌入式硬件上运行，否则你会用嵌入式硬件分发：甲骨文改变了JRE的许可，这样，它的不许可，如果上述满足条件；您需要购买 Java SE嵌入式许可证。请参阅“通用系统”对Java SE Embedded意味着什么？

— 恢复莫妮卡-M.施罗德
source