OSGi，Java模块化和拼图

因此，截至昨天早上，我对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是该镇唯一的游戏。

很简单，如果您想在当今的Java中进行基于组件的真正开发，那么OSGi是市面上唯一的游戏。

我认为，Jigsaw是对JDK中可行功能的妥协和SUN与OSGi员工之间先前不良关系的结合。也许它将随Java 8一起提供，但是我们必须拭目以待。

如果您在典型的企业环境中工作，OSGi并非万灵药，由于许多知名的图书馆（看着您，Hibernate）对类可见性进行的假设不再有效，因此您需要熟悉类加载的工作方式在OSGi中。

我喜欢OSGi，但我不会尝试将其改造为现有系统。我还要权衡新开发领域的利弊-我建议您查看能简化OSGi寿命的Apache或Eclipse产品，而不是自己动手做。

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

我喜欢您使用“角落案例”一词来描述当前情况。

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

无论如何，自从多年以来，我一直对支持创建和甚至更好执行的工具和技术感兴趣，这些工具和技术比没有它们的结果更干净，更分离，更一致，更可维护。测试驱动设计和Junit就是这样的组合。

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

而且，作为奖励，它会让您有机会做很多有趣的事情。想象一下，在演示过程中，无缝升级身份验证模块，而不会造成流量损失，以支持OAuth ...突然间，再次创建东西真是一件乐事！