OSGi、Java模块化和Jigsaw

Question

截至昨天早上，我对OSGi是什么甚至一无所知。 OSGi只是我不断看到的一些流行语，所以最终我抽出一些时间来研究它。

实际上，它似乎是相当酷的东西，所以我首先要声明（为记录）：我在任何方面都不反对OSGi，并且这不是一个“OSGi批判”的问题。

到最后，似乎OSGi基本上解决了有关Java模块化的JSR 277，该规范认识到JAR文件规范存在缺陷，在某些极端情况下可能会导致命名空间解析和类加载问题。OSGi还有很多其他非常酷的功能，但据我所知，那是它最大的优点之一。

对于我这样一个比较新的（已经几年了）Java EE开发人员来说，令人难以置信的是，我们现在处于2011年，并且正在生活在Java 7时代，而这些类加载问题仍然存在；特别是在企业环境中，其中一个应用服务器可能有数百个JAR文件，其中许多 JAR文件依赖于彼此的不同版本，并且都（或多或少）同时运行。

我的问题：

尽管我对OSGi很感兴趣，并且很想开始学习它，以查看它是否可以用于我的项目，但我现在没有时间去学习如此庞大的东西。

那么当出现这些问题时，非OSGi开发人员该怎么办？目前（Oracle / Sun / JCP）存在哪些解决方案？为什么Jigsaw从J7中被削减了？社区有多确信Jigsaw将在明年的J8中得到实施？即使它不是Java平台的一部分，您是否可以为您的项目获得Jigsaw？

我想我在这里问的是恐慌、好奇和无语的结合。现在我终于明白OSGi是什么了，但我就是不明白像Jigsaw这样的东西怎么会花20多年才能实现，并且如何将其从发布中取消。

而作为一名开发人员，我也很想知道如果没有OSGi，我的解决方案是什么。

另外，注意：我知道这并不是一个“纯编程”类型的问题，但在有些人鼻子歪掉之前，我想再次声明，我故意把这个问题放在SO上。那是因为我对我的SO同行们充满了最大的尊重，我正在寻找一些每天都可见的“IT之神”中的架构级别��案。

但是，对于那些绝对要求带有代码片段的 SO 问题的人：

int x = 9;

感谢任何能够对OSGi/Jigsaw/classloader/namespace/JAR hell问题进行解答的人！

- IAmYourFaja

---

Java 9昨天已经发布，其中包含Jigsaw。阅读以下文章很不错：揭开十大Jigsaw和Java 9的误解。 - David Tonhofer

Answer 1

首先要了解的是Jigsaw的主要用途是使JRE本身模块化。其次，它将提供一个模块系统，可供其他Java库和应用程序使用。

我的观点是，像Jigsaw这样的东西可能仅适用于JRE，但如果被其他Java库或应用程序使用，它会带来比声称解决的问题更多的问题。

JRE是一个非常困难和特殊的情况。它已经超过12年，并且是一个可怕的混乱，充满了依赖循环和无意义的依赖关系。与此同时，它被约9百万开发者使用，可能运行在数十亿的系统上。因此，如果重构会创建破坏性变化，您绝不能重构JRE。

OSGi是一个模块系统，可以帮助您（甚至是强制您）创建模块化的软件。您不能只是在现有的非模块化代码库上添加模块化功能。将非模块化的代码库转换为模块化的代码库不可避免地需要进行一些重构：将类移动到正确的包中，使用解耦服务替换直接实例化等。

这使得直接将OSGi应用于JRE代码库变得困难，但我们仍然需要将JRE分成单独的部分或“模块”，以便可以交付裁剪版本的JRE。

因此，我认为Jigsaw是一种类似于“极端措施”，以使JRE代码保持活力并将其拆分。它不会帮助代码变得更加模块化，并且我确信它实际上会增加使用它的任何库或应用程序演变所需的维护量。

最后：OSGi已经存在，而Jigsaw尚不存在，可能永远不存在。 OSGi社区在开发模块化应用方面拥有12年的经验。如果您真正有兴趣开发模块化应用程序，那么只能选择OSGi。

- Neil Bartlett

---

还有JBoss模块：https://docs.jboss.org/author/display/MODULES/Introduction 它也被Ceylon (ceylonlang.org)使用。请参阅Ceylon用户论坛上的此线程：https://groups.google.com/forum/?hl=de#!topic/ceylon-users/RmDskLDNkug - OlliP

最终声明：“如果您真正有兴趣开发模块化应用程序，OSGi是唯一的选择”是否仍然适用？ - Adam Arold

@AdamArold 我相信是这样的。Jigsaw在任何发布版本的Java中仍不存在。JSR 376（Java平台模块系统）仍在组建其专家组，甚至还没有开始第一稿。Java 9将在一年多后才发布，即使发布了也不能保证具有模块化功能（它从Java 7滑落，然后从Java 8滑落，很容易再次滑落）。最后，JSR376的已发布要求表明需要OSGi互操作性...因此采用OSGi仍然是一个安全的选择，今天也是唯一实际的选择。 - Neil Bartlett

我明白了。对我来说，微服务架构似乎正在取代模块系统的需求。再加上像Eureka这样的工具，它似乎很有效。 - Adam Arold

@AdamArold 好吧，这是一个有些不同的问题！你可以说OSGi是一种微服务架构，但我知道你想表达什么。对我来说，将每个服务建模为一个进程的想法更加复杂，涉及到管理、安全和通信开销等方面的问题。而OSGi则更简单、更快速。话虽如此，使用OSGi远程服务非常容易将服务在进程障碍中转移，因此我认为它是实施微服务的一个很好的选择技术。 - Neil Bartlett

Answer 2

如果你想在Java中进行真正的基于组件的开发，那么今天OSGi是唯一的选择。

在我看来，Jigsaw是JDK中可行内容和SUN与OSGi开发人员之间那些不良关系的妥协。也许它会随Java 8一起发布，但我们还需要等待并观察。

如果你在典型的企业环境中工作，OSGi并非万能药，并且您需要了解类加载方式，因为许多知名库（例如Hibernate）对类的可见性有了不再适用于OSGi的假设。

我喜欢OSGi，但我不会尝试将其应用于现有系统。我同样会权衡利弊，考虑到绿地开发，我建议使用简化OSGi生命周期的Apache或Eclipse产品，而不是自己动手。

如果你没有使用OSGi，那么如果你的系统依赖于相同库的不同版本，你就没什么办法了 – 你可以尝试避免这个问题，但需要多个库版本听起来像一种架构“气味”。

- SteveD

---

是的，我想到Sun和OSGi联盟之间存在很多“不和谐因素”。虽然我无法想象Oracle会让事情失控，但他们肯定不会坐视不管。你真的告诉我没有计划真正解决（而不是通过hack手段）这个JAR地狱问题吗？这让我感到震惊！ - IAmYourFaja

@Mara，说"bad blood"不是很公平。毕竟，大约12年前（JSR 8），Sun是OSGi的共同创建者之一。在Oracle收购之前大约一年，Sun也重新加入了OSGi联盟作为全体成员。他们在Oracle之前也基于OSGi开发了很多软件，最明显的例子就是Glassfish。然而可以说，在Sun/Oracle和OSGi之间存在摩擦是公平的。 - Neil Bartlett

Answer 3

我很喜欢你使用“边缘情况”这个词来描述当前的情况。

JAR文件规范存在不足，可能会在某些边缘情况下导致命名空间解析和类加载问题。

总之，多年来我一直对支持创建更干净、更松耦合、更协调、更易维护代码的工具和技术感兴趣，甚至比没有这些工具和技术产生的结果更好。测试驱动设计和Junit就是这样的组合。

在将我们代码库的相当一部分移植到OSGi花费了几个月之后，我可以说OSGi在这方面是一个更好的工具。这真的足以成为转向OSGi的充分理由。从长远来看，它能够为您节省大量资金。

而且，作为奖励，它将为您提供很多有趣的机会。想象一下，在演示期间，无缝升级身份验证模块以支持OAuth，而不会出现流量损失......重新开始创造东西真的很快乐！

- forty-two