OSGi、Java 模块化和拼图答案

【问题标题】：OSGi, Java Modularity and JigsawOSGi、Java 模块化和拼图
【发布时间】：2011-11-21 20:22:42
【问题描述】：

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

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

归根结底，OSGi 似乎 - 基本上 - 解决了 Java Modularity 上的 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。

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

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

int x = 9;

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

【问题讨论】：

嗯，Java 9 昨天就在这里，还有 Jigsaw。很高兴阅读：The Top 10 Jigsaw and Java 9 Misconceptions Debunked

标签： java osgi classloader java-platform-module-system

【解决方案1】：

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

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

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

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

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

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

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

【讨论】：

这也是你吗？ slideshare.net/mfrancis/… 几乎一样的内容。
还有JBoss Modules：docs.jboss.org/author/display/MODULES/Introduction Ceylon（ceylonlang.org）也使用它。在 Ceylon 用户论坛上查看此主题：groups.google.com/forum/?hl=de#!topic/ceylon-users/RmDskLDNkug
最后的声明是否：“如果您对开发模块化应用程序非常感兴趣，OSGi 是唯一的游戏” 仍然成立吗？
@AdamArold 我相信。 Jigsaw 仍然不存在于任何已发布的 Java 版本中。 JSR 376（Java 平台模块系统）仍在组建其专家组，甚至还没有开始起草初稿。 Java 9 的发布时间不会超过一年，即使发布也不能保证具有模块化（它从 Java 7 滑落，然后从 Java 8 滑落，并且很容易再次滑落）。最后，已发布的requirements for JSR376 声明需要 OSGi 互操作......所以采用 OSGi 仍然是一个安全的选择，也是今天唯一可行的选择。
@AdamArold 好的，这是一个不同的问题！你可以说 OSGi 是一种微服务架构，但我知道你在说什么。对我来说，将每个服务建模为一个流程的想法是一个更复杂的问题，在管理、安全和通信开销方面。 OSGi 更简单、更快速。话虽如此，使用 OSGi Remote Services 将服务转换进出进程障碍非常容易，因此我相信它是微服务实现技术的不错选择。

【解决方案2】：

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

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

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

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

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

【讨论】：

是的，我认为 Sun 和 OSGi 联盟之间有很多“不和”。不过，我无法想象甲骨文会让事情脱离他们的控制。你真的是在告诉我没有计划在短期内真正修复（而不是破解）这个 JAR 地狱的东西？这让我大吃一惊！
@Mara 说有坏血是不公平的。毕竟，Sun 是大约 12 年前（JSR 8）的 OSGi 的共同创造者之一。 Sun 还作为正式成员重新加入了 OSGi 联盟，大约比 Oracle 收购早一年。他们还在 Oracle 之前的 OSGi 之上开发了很多软件。最明显的例子是 Glassfish。然而，公平地说，Sun/Oracle 和 OSGi 的某些人之间存在摩擦。

【解决方案3】：

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

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

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

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

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

【讨论】：