Java 9迫在眉睫，它将带有完整的Project Jigsaw 。 在我从OpenJFX邮件列表的最近讨论中得知它可能会破坏现有代码之前，我并没有对此给予太多关注。 这对于Java非常不寻常，因此引起了我的兴趣。

我阅读了该项目的JEP和一些相关文章，得出的结论是，这将破坏现有代码。 是否会受到影响取决于您的项目，但是您可能会受到影响并且可能会受到伤害。

总览

在粗略介绍了Jigsaw项目的内容之后，我将描述可能发生的重大变化。

我从可用文档中编译了该更改列表。 当然不能保证我能抓住一切，并且由于我不熟悉某些概念，因此我可能会误会某些事实。 买者自负。

如果您发现错误或认为某些事情可以变得更清晰或更精确，请发表评论，我很乐意提供您的意见。

拼图项目

我可能会在某个时候写一个关于Jigsaw项目的更详细的描述，但是现在我会很懒惰，只是引用一下：

该项目的主要目标是：

• 使Java SE平台和JDK更容易地扩展到小型计算设备；
• 总体上提高Java SE平台实现（特别是JDK）的安全性和可维护性；
• 改善应用程序性能； 和
• 使开发人员更容易为Java SE和EE平台构建和维护库和大型应用程序。

为了实现这些目标，我们建议为Java SE平台设计和实现一个标准模块系统，并将该系统应用于平台本身以及JDK。 该模块系统应具有足够的功能以模块化JDK和其他大型遗留代码库，但仍可供所有开发人员采用。

拼图项目现场– 2015年2月11日

如果您想了解更多有关该项目的信息，请查看其站点 ，尤其是目标和要求列表 （当前版本为2014年7月起的草案3 ）。

这里要带走的主要东西是模块系统。 从版本9开始，可以将Java代码（以及JRE / JDK）组织在模块中， 而不是 JAR文件中。

发布时间由约尔·本·亚伯拉罕在CC-BY-ND 2.0 。

破码

这听起来像是内部重构，那么为什么要破坏现有代码？ 好吧，它并不一定要这样做，兼容性甚至是项目的核心要求之一（与Java一样）：

仅使用标准Java SE API以及可能还使用特定于JDK的API的应用程序必须以与今天相同的方式运行[…]。

拼图项目：目标与要求–草稿3

重要的部分是限定条件“仅标准API”。 有很多方法可以创建应用程序，这些应用程序的某些关键细节依赖于未指定或不建议使用的属性，例如非标准API，未记录的文件夹结构和JAR文件的内部组织。

因此，让我们看看潜在的重大变化。 有关更多详细信息，请确保检查项目的站点，尤其是JEP 220 ，该站点包含对随后大部分内容的更精确描述。

内部API变得不可用

使用JAR文件，任何公共类在JVM中的任何位置都是可见的。 这严重限制了JDK实现将内部API保持私有状态的能力。 取而代之的是许多方法都是可访问的，并且出于各种原因而经常使用它们（例如，为了提高性能或解决Java运行时中的[先前]错误； Java FAQ解释了为什么这样做可能不是一个好主意 ）。

这随模块而改变。 每个模块都可以明确声明哪些类型作为其API的一部分可用。 JDK将使用此功能来正确封装所有内部API，因此将不可用。

事实证明，这可能是与Java 9不兼容的最大原因。由于它会引起编译错误，因此它肯定是最不敏感的。

为了准备Java 9，您可以检查代码是否依赖于内部API。 您找到的所有东西都必须以一种或另一种方式替换。 一些变通办法可能已变得不必要。 其他类可能会进入公共API。 要确定是否存在这种情况，您必须进行研究，甚至可能要在OpenJDK邮件列表中询问您感兴趣的功能。

内部API

那么什么是内部API？ 绝对是所有生活在sun.*东西。 我无法确认com.sun.*所有内容是否也都是私有的-当然有一部分是但不是全部？

可能证明特别有问题的两个示例是sun.misc.Unsafe和com.sun.javafx.*所有内容。 显然，前者已在许多项目中用于执行任务和性能关键代码。 根据个人经验，我可以说后者是正确构建JavaFX控件的关键要素（例如，所有ControlsFX都依赖于这些软件包）。 还需要解决许多错误。

考虑将这两种特殊情况都转换为公共API（请参阅Unsafe和JavaFX ，尽管有些人宁愿看到Unsafe死于火灾 ）。

工具支援

幸运的是，您不必手动找到这些依赖项。 从Java 8开始，JDK包含Java Dependency Analysis Tool jdeps （ 一些内部软件包的介绍， Windows和unix的官方文档），它可以列出项目所依赖的所有软件包。

如果使用-jdkinternals参数运行它，它将输出项目使用的所有内部API –恰好是Java 9发行之前必须处理的内部API。

JDK和JRE的合并

Project Jigsaw的主要目标是Java平台的模块化，以允许灵活地创建运行时映像。 因此，JDK和JRE失去了其独特的特性，并成为一系列模块组合中的两个可能的点。

这意味着这两个工件将具有相同的结构。 这包括文件夹结构以及任何依赖于该结构的代码（例如，通过利用JDK文件夹包含子文件夹jre的事实）将无法正常工作。

内部JAR变得不可用

内部JAR（例如lib / rt.jar和lib / tools.jar）将不再可访问。 它们的内容将以故意未指定且可能更改的格式存储在特定于实现的文件中。

假设这些文件存在的代码将停止正常工作。 由于IDE或类似工具严重依赖这些文件，因此这也可能导致过渡方面的麻烦。

运行时图像内容的新URL架构

一些API在运行时将URL返回到类和资源文件（例如ClassLoader.getSystemResource ）。 在Java 9之前，这些是jar URL ，它们具有以下形式：

jar:file:<path-to-jar>!<path-to-file-in-jar>

Jigsaw项目将使用模块作为代码文件的容器，并且不再提供各个JAR。 这需要一种新格式，因此此类API会返回jrt URL ：

jrt:/<module-name>/<path-to-file-in-module>

使用此类API返回的实例来访问文件的代码（例如，使用URL.getContent ）将像今天一样继续工作。 但是，如果它取决于jar URL的结构 （例如，通过手动构造它们或解析它们），它将失败。

取消认可的标准替代机制

Java API的某些部分被视为独立技术，并在Java社区流程（例如JAXB ）之外创建。 可能需要独立于JDK进行更新或使用替代实现。 认可的标准替代机制允许将这些标准的替代版本安装到JDK中。

此机制在Java 8中已弃用，在Java 9中将被删除。其替代品是可升级模块 。

如果您从未听说过此消息，则可能不使用它。 否则，您可能想验证您使用的实现是否将成为可升级模块。

删除扩展机制

使用扩展机制，自定义API可以提供给JDK上运行的所有应用程序使用，而不必在类路径上命名它们。

此机制在Java 8中已弃用，在Java 9中将被删除。一些有用的功能将保留。

如果您从未听说过此消息，则可能不使用它。 否则，您可能需要检查JEP 220以获得详细信息。

Java 9的准备

这些变化共同给任何大型项目过渡到Java 9带来了风险。评估和减少它的一种方法可能是“更新高峰”：使用jdeps识别对内部API的依赖性。 修复这些问题之后，请花一些时间来使用Java 9早期访问版本之一来构建和运行项目。 彻底测试系统的相关部分，以了解可能出现的问题。

通过这种方式收集的信息可以返回到项目，例如，通过将其发布在Jigsaw-Dev邮件列表中 。 引用JEP 220的（几乎）最后的话：

不可能确定摘要中这些更改的全部影响。 因此，我们必须依靠广泛的内部测试，尤其是外部测试。 […]如果其中某些更改被证明对开发人员，部署人员或最终用户而言是无法克服的障碍，那么我们将研究减轻其影响的方法。

反射与监视

我们已经看到Project Jigsaw将模块化Java运行时。 内部API（软件包sun.*以及com.sun.* ）将不可用，并且JRE / JDK的内部结构将发生变化，包括文件夹和JAR。 在Java 8中弃用它们之后，认可的标准覆盖机制和扩展机制将在Java 9中删除。

如果您想帮助您的朋友和追随者为Java 9做准备，请确保分享这篇文章。

到目前为止，我们专注于Jigsaw项目的问题方面。 但这不应偏离计划中的令人振奋的，而且我认为非常积极的性质。 阅读文档后，我对即将发布的Java版本的范围和潜力印象深刻。 尽管对于单个开发人员而言，它可能不像Java 8那样具有突破性，但对于参与构建和部署的每个人（尤其是大型整体项目）而言，甚至更是如此。

因此，我一定会再次撰写有关拼图计划的文章-然后着重介绍好的方面。 如果您想了解更多信息，请继续关注。

翻译自: https://www.javacodegeeks.com/2015/04/how-java-9-and-project-jigsaw-may-break-your-code.html