java - OSGi、Java 模块化和拼图

Question

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

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

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

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

我的问题:

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

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

我想我在这里要问的是 panic 、阴谋和捂脸的组合。现在我终于明白了什么是 OSGi，但我只是不“明白”像 Jigsaw 这样的东西是如何用了 20 多年才实现的，以及它是如何从一个版本中删除的。 这似乎是基本的。

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

另外，注意:我知道这不是一个“纯编程”类型的问题，但在你们中的一些人 Nose 弯曲之前，我想声明(再次记录在案)我故意把这个问题放在 SO 上。那是因为我对我的 SOers 同胞怀有最大的尊重，我正在从我每天看到的一些“IT 之神”那里寻找架构级别的答案。

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

int x = 9;

(感谢任何可以权衡这个 OSGi/Jigsaw/classloader/namespace/JAR hell 的东西!)

Answer 1

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

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

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

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

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

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

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