java9模块化_“ Java 9可以实现模块化，就像Java 8可以实现功能编程一样”

java9模块化

您最喜欢的功能是什么？为什么？

Nicolai Parlog：绝对强大的封装！ 当我们创建模块时，模块外部的代码只能访问导出包中的公共类型。 这使我们可以在同一模块内的包之间共享代码，而无需外部代码开始使用它。

强大的封装为私有-公共轴增加了另一个选择，我坚信， exported将像今天的private和public一样成为我们设计不可或缺的一部分。

JAXenter：是否有您想在Java 9中看到但未包含的功能？

Nicolai Parlog：如果一个库将其模块名称从一个版本更改为另一个版本，则最终可能会得到一个应用程序，该应用程序可传递地依赖于该模块，但使用两个不同的名称进行引用。 就目前而言，模块系统没有解决此类死锁的好方法-无法启动应用程序。

因此，我希望看到一种命令行选项形式的别名机制，该机制允许用户将一个模块替换为另一个模块。 诸如--alias-module guava=com.google.guava类的东西，其中所有依赖项，合格导出或提及guava的其他子句都将被视为好像提到了com.google.guava 。

不过，我认为我几乎是唯一一个认为这是一个好功能的人，因此没有实施它就很有意义。 而且，由于释放周期更快，因此危害不大，因为如果发现这种死锁会带来麻烦，则可以非常快速地发货。

您如何看待模块系统？

Nicolai Parlog：我的发布商有合同规定我必须全心全意地爱模块系统。

但是，认真地说，我认为拥有一流的机制来建模工件之间的关系并在该级别上支持模块化非常重要。 一个小例子是，堆栈跟踪现在告诉我们方法属于哪个模块。 这表明JVM最终将JAR视为不仅仅是容器，并赋予了它们自己的生命。

当然， 模块系统的其他目标更为重要：

• 可靠的配置（模块表达依赖性）
• 强封装（请参阅前面）
• 可扩展平台（仅使用所需模块创建运行时映像）
• 改进的安全性（许多代码现在由JPMS自动保护，而不是由安全管理器手动保护）
• 提高了JDK的开发速度（模块化的JDK使更改变得更加容易）

我坚信，这些方面将提高Java生态系统中许多项目的质量。 诚然，与Java 8中的lambda和流相比，它们以不那么明显的方式出现。每个开发人员都可以立即看到他们如何更改代码的编写方式–使用模块系统，效果更加间接。

尽管两个版本之间存在差异，但我实际上还是喜欢与Java 8进行比较。 它使社区接触到了函数式编程的概念，并了解了创建的库，文章，演讲和书籍的数量-与四年前相比，我们现在的状况要好得多，因为我们对这些概念有了更好的了解。 我希望Java 9在模块化方面也能做到这一点。 （我肯定从模块化设计的原理中学到了很多东西。）我很高兴看到它如何发挥作用。

JAXenter：您是否将开始使用或不使用模块？

Nicolai Parlog：这完全取决于项目。 如果它已经存在并且具有庞大的代码库（已经迁移到Java 9 ），则对其进行模块化将需要时间，并且为了获得良好的结果，不应匆忙。 相反，应该抓住这个机会来修复项目的结构。 因此，在那种情况下，我会投票支持模块，但步伐缓慢。

对于针对Java 9的新项目，模块将是我的默认设置。 自动模块和未命名模块不仅允许增量模块化，而且还使新项目可以模块化，即使其依赖项尚未发布模块也是如此。

一个重要的例外是公开可用的库和框架。 只有在其非模块化依赖项已在清单中定义了模块名称的情况下，才应装运模块。 不应发布任何需要使用基于JAR文件名的自动模块的模块。 Maven甚至对此有所警告。

相反，它成为Java 9的主要功能-值得等待吗？

Nicolai Parlog：这是一种奇怪的观察方式。 我是否愿意看一下Java 8中的模块系统？ 当然！

但是，Java 8于三年前问世，当时模块系统仍在开发中。 再过了18个月，甚至一个原型都无法在2015年末发布。此后投入的大量工作和讨论对于我们现在得到的结果而言是无价的。 没有这些，模块系统将完全不适合目标用途，因此将其安装在8中绝不是真正的选择。

您认为更改它是个好主意吗？

Nicolai Parlog：确实有一些关于版本计划的讨论，但是在我深入探讨之前，我想澄清一下，尽管这是最近公告中最具争议的方面，但它也是最不重要的。 快速的发布周期，GPL许可的OpenJDK，开源的专有工具以及使Oracle JDK和OpenJDK总体协调一致，这些都是伟大的决策，受到了几乎所有人的一致好评。

发电厂解决后，让我们转向自行车棚：我强烈不喜欢新版本的方案。 一开始，我只是觉得这很奇怪，但是思考的时间越长，我就越不喜欢它。 我写了一个每周通讯（ 通过邮件和在Medium上发布 ）并在那里进行了详细讨论 。 综上所述：

• 我不太关心版本发布的年份，更不用说月份了-为什么将不重要的信息如此突出？
• year.month看起来像语义版本控制（ 新的Version类支持一种解释），但不是
• 如果在三月或九月以外的其他月份发布了新版本，则情况将变得非常混乱。 （“因此，有18.3和18.10，然后是19.3和19.9？”）
• 可用版本的空间受到“污染”-当（ 如果不是）此方案更改时，下一个版本不可避免地会达到20左右
• 每个Java新手都必须了解这一点，因此他们不会去寻找不存在的版本

我希望版本控制方案与现在的版本保持非常相似。 当前的提案计划在每个发行版之前冻结三个月的功能–应该有足够的时间来决定更改是否需要增加字节码级别和主要版本或次要版本来满足。 因此，也许2018年给我们带来9.1。 和9.2，但2019年3月具有原始专业化（只是一个假设！），所以我们得到10.0。

这意味着什么，用户为什么要走专有路线？

尼古拉·帕洛格（Nicolai Parlog）：我不在这里。 自从意识到有不同的JDK使用Oracle以来，我曾经从事过的所有项目，所以我不确定切换到OpenJDK的方式会如何体现出来。 总的来说，我相信自由软件的价值和潜力，因此，我对这一举动表示赞赏。

JAXenter：Java 9对开发人员是否像Java 8一样有趣？

Nicolai Parlog：我已经讨论了模块系统的影响，这对lambda的影响远不及日常编码。 恐怕会使开发人员对它的兴趣降低，但是我认为这对他们来说并不重要。 正如我所说，我认为Java 9可以实现模块化，就像Java 8可以实现功能编程一样。

但是，Java 9不仅仅是模块系统， 它带来的许多其他变化也非常酷！ 专用接口方法，收集工厂， 对Stream和Optional API的 改进 ，多版本JAR等等……清单不胜枚举。

它们都不是杀手级功能，但是每个功能都解决了一个具体问题，该问题至少困扰了Java社区的某些部分，我发现解决这些问题真是太棒了。 总之，它们将显着改善我们日复一日编写的代码。 对于开发人员来说，这怎么可能没有意思呢？

谢谢！

翻译自: https://jaxenter.com/nicolai-parlog-java-9-interview-137958.html

java9模块化