94

因此，截至昨天早上，我对 OSGi 甚至是什么一无所知。OSGi只是我不断看到的一个流行词，所以我终于抽出一些时间来复习它。

它实际上看起来很酷，所以我想首先声明（记录在案）我在任何方面都不是反 OSGi，这也不是一些“抨击 OSGi”的问题。

归根结底，OSGi 似乎 - 基本上 - 解决了 Java 模块化的JSR 277，它认识到JAR文件规范存在缺陷，在某些极端情况下可能导致命名空间解析和类加载问题。OSGi 还做了很多其他非常酷的东西，但据我所知，这是它最大的吸引力（或其中之一）。

对我来说——作为一个相当新的（几年前）Java EE 开发人员，我们在 2011 年并且目前生活在 Java 7 时代，而且这些类加载问题仍然存在，这绝对是令人难以置信的；尤其是在企业环境中，一个应用服务器上可能有数百个 JAR，其中许多依赖于彼此的不同版本，并且都（或多或少）同时运行。

我的问题：

尽管我对 OSGi 很感兴趣，并且我想开始学习它以了解它在哪里/是否对我的项目有用，但我只是没有时间坐下来学习那么大的东西，至少现在。

那么当这些问题出现时，非 OSGi 开发人员应该怎么做呢？当前存在哪些Java (Oracle/Sun/JCP) 解决方案（如果有）？Jigsaw为什么会从J7中删减？Jigsaw 明年将在 J8 中实施的社区有多大把握？即使它还不是 Java 平台的一部分，是否有可能为您的项目获取 Jigsaw？

我想我在这里要问的是恐慌、阴谋和面子的结合。现在我终于明白了什么是 OSGi，我只是不“明白”像 Jigsaw 这样的东西是如何用了 20 多年才实现的，然后又是如何从一个版本中删除的。这似乎是基本的。

而且，作为一名开发人员，我也很好奇我的解决方案是什么，没有 OSGi。

另外，注意：我知道这不是一个“纯编程”类型的问题，但在你们中的一些人鼻子弯曲之前，我想声明（再次，为了记录）我故意提出这个问题所以。那是因为我对我的 SOers 同胞表示最大的尊重，我正在从我每天看到的一些“IT 之神”那里寻找架构级别的答案。

但是，对于那些绝对坚持用一些代码段支持 SO 问题的人：

int x = 9;

（感谢任何可以权衡这个 OSGi/Jigsaw/classloader/namespace/JAR 地狱的东西的人！）

4

3 回答 3

101

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

我的立场是，像Jigsaw 这样的东西可能仅对 JRE 是必需的，但如果其他 Java 库或应用程序使用它，它会产生比它声称要解决的问题更多的问题。

JRE 是一个非常困难和特殊的情况。它已经超过 12 年了，而且是一团糟，充满了依赖循环和荒谬的依赖。同时被大约900 万开发人员和可能数十亿个正在运行的系统使用。因此，如果重构造成重大更改，您绝对不能重构 JRE。

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

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

因此，我将 Jigsaw 视为一种“极端措施”，以在拆分 JRE 代码的同时保持其活力。它无助于代码变得更加模块化，而且我相信它实际上会增加开发使用它的任何库或应用程序所需的维护。

最后：OSGi 存在，而 Jigsaw 尚不存在并且可能永远不会存在。OSGi 社区在开发模块化应用程序方面拥有 12 年的经验。如果您对开发模块化应用程序非常感兴趣，那么 OSGi 是城里唯一的游戏。

于 2011-09-21T13:06:47.470 回答
21

这很简单，如果你想在今天用 Java 进行真正的基于组件的开发，那么 OSGi 是城里唯一的游戏。

在我看来，Jigsaw 是对 JDK 中可行功能和 SUN 与 OSGi 人员之间的不良关系的妥协的结合。也许它会随 Java 8 一起发布，但我们必须拭目以待。

如果您在典型的企业环境中工作，OSGi 并不是灵丹妙药，您需要熟悉类加载的工作原理，因为许多知名库（看看您，Hibernate）对不再有效的类可见性做出假设在 OSGi 内部。

我喜欢 OSGi，但我不会尝试将其改装到现有系统中。我还会权衡在未开发开发方面的利弊——我建议查看简化 OSGi 生活的 Apache 或 Eclipse 产品，而不是全部自己做。

如果您不使用 OSGi，那么如果您想出了一个依赖于同一库的不同版本的系统，那么您将不走运——您所能做的就是尝试避免该问题，尽管需要多个版本图书馆对我来说似乎是一种建筑“气味”。

于 2011-09-21T11:54:12.357 回答
15

我喜欢你用“极端情况”这个词来描述当前的情况。

JAR 文件规范存在一些缺陷，在某些极端情况下可能会导致命名空间解析和类加载问题

无论如何，多年来我一直对支持创建甚至更好地执行代码的工具和技术感兴趣，这些代码比没有它们的结果可能更干净、更解耦、更连贯和更易于维护。测试驱动设计和 Junit 就是这样的组合。

在花了几个月的时间将我们的大部分代码库迁移到 OSGi 之后，我想说 OSGi 在这方面是一个更好的工具。这确实是迁移到 OSGi 的充分理由。从长远来看，它将为您节省很多钱。

而且，作为奖励，它会让你有机会做很多很酷的事情。想象一下，在演示期间，无缝升级身份验证模块，没有流量损失，以支持 OAuth ......突然又开始创造东西了！

于 2011-09-21T20:27:15.600 回答