拼图问题为1000。我作为X想要JPMS模块。 如果不是平台开发人员，X是什么？

我的回答是X是人（减去平台开发人员，因为那是一个条件） 。 我们都需要模块系统具有更安全的代码，从而产生更可靠的系统，从而带来更好的业务绩效，带来更好的经济效益并带来人类幸福。 也许我得出的结论有点过头了，但重点是，无论是否意识到，行业内的每个人都需要模块系统。 你会得到的。 首先，我们应该从问题的先前答案开始。

Nicolai Parlog说： 每个类型不是全部公开的库开发人员。

非常真实 作为一个库开发人员，我想设计我的库，以便分离API。 我希望将公共接口与实现分开。 这就是我们程序员所说的“封装”。 封装起来太好了。 我们喜欢这样做！ 我们这样做，因为它很有趣！ 我们喜欢它！

关于第二个想法，尽管我们这样做是因为它是一种创建可靠的无错误软件的工具。

它帮助使用我的代码封装内部状态和实现的代码开发人员编写更好的代码。 这有点像抚养孩子。 作为父母，我不允许他们做某些事情。 多吃巧克力，熬夜等等。 即使他们暂时看不到它，这也是为了他们自己的利益。 当然，后来，当他们长大并自己成为父母时，他们将理解并做同样的事情。 对于库开发人员和使用程序员的库来说，没有什么不同，除了，也许程序员永远不会长大。

同样，作为图书馆开发人员，我要使用JPMS，以便于使用我的代码的开发人员。 我的库不会仅仅因为封装而好坏。 （附带说明：这会更好，但不是因为其中的错误数量减少了。）我可以很容易地暗示我作为图书馆开发人员的需求最少。 亲爱的程序员，谁在乎您是否使用我的库来射杀您的睾丸？ 您有责任仅调用公共API，而不是一些经常修改的内部类和方法。 还是？

并不是的。 创建易于使用且难以出错的库也是我的责任。 这就是我们所说的可用性。 这是JPMS模块系统出现的地方。 没有JPMS，我可以记录哪些软件包是公共的，哪些是特定于实现的。 我与图书馆用户之间的约定是，他们将不使用图书馆的私有资源，因此，出于这种良好行为，我将使图书馆的公共部分保持稳定，以便他们无需在发行版本之间更改代码。 。 （顺便说一句，有没有人意识到这个名字，jPMS是多么的血腥？是什么？PMS，真的吗？更不用说看到与此有关的所有抽筋了：nomen est omen。这不是幸运的洗礼。）

让我们回到轨道上：为什么我们需要为此使用模块系统？ 开发人员是纪律严明的人，他们不想伤害自己。 他们不应该，也不会使用库的内部代码。 从长远来看，这对他们不利，他们深知这一点。 从长远来看这很麻烦。 从长远来看，我们都死了。 在开发过程中，通常会在发布日期之前的几天，使用某个库的某些内部API似乎很有利可图。 以某种怪异的方式，这些内部调用正是您所需要的。 您知道不应该使用它们，并且有一个很好的，礼貌的解决方案，但这需要更多的时间来开发。 只是随着发布日期的临近，您没有时间遵循这种模式。 更不用说为“我能做到”而自豪，“我对这些工具的了解程度”，而不是为羞辱篡改图书馆的私有部分而感到自豪。

这就是Java Module System出现的地方。 您将无法执行快捷方式。 您会感叹过去Java面向全世界开放的美好时光，无论类加载器上有什么（更不用说FORTRAN编程，对还是对？），但是您将遵循规则，因为它否则将无法正常工作。

您认为使用库的内部组件并不容易受到虚荣的影响。 这是一个测试：您是否认识到我使用了“库的内部API”这一表达？ 如果没有，那就感到羞耻，但不要承认。 没必要。 Java模块系统将有助于忘记不存在的事物，例如内部API。 废话。 API是公开的。 没有内部API之类的东西。 生成的代码将更好，更易于维护，不容易进行库升级，从而降低成本。

从长远来看，当我们全都死了时，我们的后代将创建更好的代码，并且具有模块级封装将是显而易见的事情，就像那时世界和平一样。

因此，我需要Java模块系统，您需要它，其他每个人都需要它来建立一个更好的世界并实现世界和平。

免责声明：本文的作者没有以英语为母语

翻译自: https://www.javacodegeeks.com/2017/05/needs-java-modules.html