迁移到Java 9或更高版本时是否需要切换到模块？

我们目前正在从Java8迁移到Java11。然而，升级我们的服务没有我们预期的那么痛苦。我们基本上只需在

build.gradle

文件中更改版本号，服务就可以愉快地启动并运行了。我们升级了图书馆以及使用这些库的（微型）服务。到现在为止没有问题

是否需要实际切换到模块？这将产生不必要的成本。如有任何建议或进一步阅读材料，我们将不胜感激

---

为了明确起见，如果使用Java9+代码而不引入模块，会有什么后果吗？例如，它是否会与其他代码不兼容？

我只能告诉您我的组织对此事的看法。对于我们正在进行的每个项目，我们都在向模块转移。我们正在构建的基本上是微服务+一些客户端库。对于微服务来说，向

模块的转换在某种程度上是一个较低的优先级：那里的代码在docker容器中已经以某种方式被隔离，因此（对我们来说）“添加”模块似乎并不重要。这项工作进展缓慢，但优先级较低

另一方面，客户端库是一个完全不同的故事。我不能告诉你我们有时有多么混乱。我将解释一个我以前讨厌的问题
jigsaw
。您向客户机公开一个接口，供每个人使用。自动将
界面
公开

——向世界公开。通常，我要做的是，拥有一些

包私有的

类，这些类不向使用该接口的客户机公开。我不希望客户使用它，它是内部的。听起来不错？错

第一个问题是，当那些

package private

类增长时，您需要更多的类，保持所有内容隐藏的唯一方法是在同一个包中创建类：

当它增长时（在我们的例子中是这样），这些包太大了。你说要换一个单独的包裹吗？当然可以，但是

HelperUsage

和

FactoryUsage

将是

public

，我们从一开始就试图避免这种情况

问题二：客户机的任何用户/调用方都可以创建相同的包名并扩展这些隐藏类。这已经发生在我们身上好几次了，很有趣

modules

以一种漂亮的方式解决了这个问题：

public

不再是真正的

public

；我可以通过

exports to

指令访问

friend

。这使我们的代码生命周期和管理更加容易。这样我们就远离了类路径地狱。当然，

maven/gradle

主要是为我们处理这个问题，但是当出现问题时，痛苦将是真实的。还有很多其他的例子

也就是说，转型（仍然）并不容易。首先，团队中的每个人都需要保持一致；其次是障碍。我现在看到的最大的两个问题是：如何根据具体的内容来划分每个模块？我还没有一个明确的答案。第二个是

splitpackages

，哦，漂亮的“相同的类由不同的模块导出”。如果这种情况发生在您的库中，那么有一些方法可以缓解；但如果这些是外部库。。。没那么容易

如果您依赖于

jarA

和

jarB

（单独的模块），但它们都导出

abc.def.Util

，那么您会感到惊讶。不过，有办法解决这个问题。某种程度上是痛苦的，但可以解决

总的来说，自从我们迁移到模块（现在仍然如此），我们的代码变得更干净了。如果你的公司是“代码第一”公司，这很重要。另一方面，我也参与过一些公司，这些公司被高级架构师视为“太贵”，“没有真正的好处”

不需要切换到模块

从来没有必要切换到模块

Java9及更高版本支持服务器上的传统JAR文件 传统的类路径，通过未命名模块的概念，将 很可能一直到宇宙热死

是否开始使用模块完全取决于您

如果您维护一个变化不大的大型遗留项目， 那么这可能不值得努力

如果你在一个大项目上工作，而这个项目在过去几年里变得很难维护 接下来的几年里，模块化带来了清晰性和纪律性 这可能是有益的，但也可能是大量的工作，所以想想吧 开始之前要小心

如果你要开始一个新项目，我强烈建议你从 如果可以的话。到目前为止，许多受欢迎的图书馆都有，所以有一个很好的例子 可能您需要的所有依赖项都已可用 以模块化的形式

如果你有一个图书馆，我强烈建议你 如果您还没有将其升级为模块，并且 您的库的依赖项已转换

所有这些并不是说你不会遇到一些绊脚石 当经过Java8时。但是，你遇到的人会， 可能与模块本身无关。最常见的 自年发布Java9以来，我们就听说了迁移问题 2017年与 （例如，

sun.misc.base64解码器

）支持哪些公共的

---

替代品已经存在多年了。

这与您在Java 8中已经面临的风险相同：最终会陷入“类路径地狱”。这在一定程度上可以解决问题。您可以检查项目目标是否与项目一致。除此之外，在我看来，对于为其用户提供支持的库/服务来说，更新也是一个重要的问题。@Taschi我不认为只有类路径地狱才有理由进行模块化，因为Java 9之前的所有代码都有这个问题，而且在大多数情况下，我们对它没有意见（我个人从来没有这样做过）

  package abc:
        -- /* non-public */ Usage.java
        -- /* non-public */ HelperUsage.java
        -- /* non-public */ FactoryUsage.java
        ....