OSGi，Java模块化和拼图

越欣怡

2023-03-14

问题内容：

因此，截至昨天早上，我对OSGi到底是什么一无所知。 OSGi 只是一个流行语，我不断看到它反复出现，因此我终于拨出一些时间来仔细研究它。

实际上，它看起来很酷，因此，我想（从记录开始）说我在任何方面都不是反OSGi的，这也不是“打击OSGi”的问题。

归根结底，似乎OSGi实质上已经解决了Java Modularity上的JSR
277
，该文件认识到JAR文件规范存在缺陷，在某些特殊情况下可能导致名称空间解析和类加载问题。OSGi还做很多其他非常酷的事情，但是据我所知，这是它最大的吸引力（或其中之一）。

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

我的问题：

就像我对OSGi一样感兴趣，并且想开始学习它，以了解它在我的项目中的用途/是否有用，我只是没有时间坐下来学习那么大的东西，至少现在。

那么，出现这些问题时非OSGi开发人员该怎么办？ 当前存在哪些 Java （Oracle / Sun /
JCP）解决方案？为什么从J7切割拼图？社区对Jigsaw明年在J8中实施的信心如何？即使它不是Java平台的一部分，也可以为您的项目获取Jigsaw吗？

我想我想问的是恐慌，阴谋和面部手掌的结合。现在，我终于了解了OSGi是什么，我只是不“了解”像Jigsaw这样的东西花了20多年的时间才能实现，然后如何从发行版中将其固定下来。
这似乎是基本的。

而且，作为开发人员，对于OSGi，我也对自己的解决方案感到好奇。

另外， 请注意 ：我知道这不是一个“ 纯粹的编程
”类型的问题，但是在你们中的一些人弯腰之前，我想声明一下（再次记录），我故意将这个问题放在上面所以。那是因为我对同胞SOers表示最大的敬意，我正在寻找我每天都潜伏在这里的一些“
IT之神”的体系结构级别的答案。

但是，对于绝对坚持 SO问题带有某些代码段的那些人：

int x = 9;

（感谢任何可以使用此OSGi / Jigsaw / classloader / namespace / JAR地狱东西的人！）

问题答案：

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

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

JRE是一个非常困难且特殊的情况。它已经超过12年了，是一个可怕的烂摊子，到处都是依赖周期和荒谬的依赖。同时，大约有 900万 开发人员使用了大约
数十亿 个正在运行的系统。因此，如果重构造成重大变化，则您绝对无法重构JRE。

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

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

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

最后：OSGi存在，而拼图尚不存在，可能永远不存在。OSGi社区在开发模块化应用程序方面拥有12年的经验。如果您对开发模块化应用程序非常感兴趣，则OSGi是该镇唯一的游戏。