经过几年的努力，我们终于开始在软件级别方面将我们的应用程序从黑暗时代中拉出来，其中一个步骤是将我们的Java版本升级到Java7。在大多数情况下，这相当轻松，但是有一些惊喜：

• 当我们切换到Java 7时，已经运行了好几年的测试用例开始失败。事实证明，我们有一些测试用例依赖于同一类中的先前测试用例。 这在两个方面都是不好的：1）测试用例应该各自独立； 2）测试类中测试用例的执行顺序是不能保证的，尽管到目前为止（在Java 7之前），顺序是找到的在源代码中。 我发现此链接有助于解释不一致情况
  我在Eclipse中看到的排序。 这不是Java 7的问题，而是我们的测试用例。 当我们开始使用Java 7时出现的一些东西
• 我们的Swing客户开始抛出ClassCastExceptions ，并且该代码已经存在了10多年了，可以追溯到Java 1.4。读取javadocs可以解释这个问题，但是我决定进行更多研究以找出发生这种情况的确切原因。现在。 我们正在向TreeSet中添加条目，以保存FocusManager的前进和后退遍历键，并将KeyStroke对象放入TreeSet中。 Javadoc明确指出放置在TreeSet（或下面的TreeMap）中的对象必须是可比较的，或者您需要使用Comparator创建TreeSet以便对这些对象进行排序。 我们什么都不做，也没有例外。 深入研究Java源代码，我发现从Java 7开始，TreeMap类已开始强制执行此“要求”，在该类的早期版本中该代码已被注释掉，因此实际上并不需要比较器。 修复很容易，我创建了一个KeyStrokeComparator并将其传递给TreeSet构造函数。
• 我还注意到，我们的Java jar签名已开始记录有关证书无效的警告。 为了保持构建的整洁而不发出这些警告，我进行了一些搜索，发现了一些与Java 7相关的帖子，并从代码签名证书中删除了MD2withRSA算法。 我在Verisign的支持下工作，以帮助从证书链中删除该算法，并且警告消失了！ 不幸的是，这还没有结束代码签名问题。
• 接下来，我们的Web Start客户端将不再成功启动，而是引发异常，至少在开发过程中，Web起始程序经常会遇到“ 并非所有罐子都使用同一证书签名的错误消息”错误消息。 我写了另一篇关于如何帮助调试的博客文章 ，认为这只是“常见的可疑罐子之一”，我们有问题，但不是，不是。 知道自证书更新以来所有这一切都发生了，这使我检查了所有已签名的罐子以寻找线索。 所有罐子均已使用相同的证书签名，但是在删除链条目之前，对第三方罐子进行了签名，而在更改证书后，我们的应用程序代码已作为构建过程的一部分签名。 这使我相信，即使罐子是用相同的证书签名的，在更改证书之前和之后签名的罐子之间也必须有一些区别。

对jar进行签名后，将在jar内的MANIFEST.MF文件中生成条目，对于jar中的每个类一个条目。 这些条目包含类的名称以及一些签名算法信息，并且在查看MANIFEST.MF文件之后，我发现了区别。 更改前签名的第3方jars包含每个类的SHA1-Digest条目，但从当前版本签名的jars中包含SHA-256-Digest条目。 用更新的证书重新签名所有的第3方jar可以解决大多数问题。 我们在重新签名过程中遇到了一个小问题，在该过程中，我们用自己生成的版本重写了现有的MANIFEST.MF，这导致了几个jar文件出现问题，这些jar文件在清单文件中包含其他服务提供商信息。

全天工作！ 很高兴成为Java领域的最新专家。 接下来，迁移到EJB3和Hibernate 3或4。

希望这可以帮助！

翻译自: https://www.javacodegeeks.com/2013/05/minor-gotchas-from-migration-to-java-7.html