OSGi,Java模块化和拼图

Question

所以截至昨天早上我还没有找到OSGi甚至是什么的线索.OSGi只是一些流行语,我一直看到它一遍又一遍地出现,所以我终于留出一些时间来了解它.

它实际上看起来很酷,所以我想首先说明(对于记录)我在任何方面都不反OSGi,这也不是一个"OSGi-bashing"问题.

在一天结束时,似乎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？

我想我在这里问的是恐慌,阴谋和一个facepalm的组合.现在我终于明白了OSGi是什么,我只是不"得到"像Jigsaw这样的东西需要20多年才能实现,然后才能从发布中获得.这看起来很基本.

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

另外,注意:我知道这不是一个" 纯编程 "类型的问题,但是在你们中的一些人让你的鼻子弯曲变形之前,我想说明(再次,为了记录)我故意把这个问题放在所以.那是因为我对我的同伴SOE只有最大的尊重,我正在寻找一些我所看到的每天潜伏在这里的"IT之神"的建筑级答案.

但是,对于那些绝对坚持使用某些代码段支持SO问题的人:

int x = 9;

(感谢任何能够权衡这个OSGi/Jigsaw/classloader/namespace/JAR地狱的人!)

Answer 1

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

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

JRE是一个非常困难和特殊的案例.它已经超过12年了,是一个可怕的混乱,充满了依赖循环和荒谬的依赖.与此同时,约有900万开发人员和数十亿运行系统使用它.因此,如果重构创建了重大更改,则绝对无法重构JRE.

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

这使得很难将OSGi直接应用于JRE代码库,但我们仍然需要将JRE拆分为单独的部分或"模块",以便可以交付JRE的简化版本.

因此,我认为Jigsaw是一种" 极端措施 ",可以在分割JRE代码时保持JRE代码的存在.它无法帮助代码变得更加模块化,而且我确信它实际上会增加进化任何使用它的库或应用程序所需的维护.

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

@AdamArold好的,这是一个不同的问题!你可以说OSGi是一个微服务架构,但我知道你在说什么.对我来说,在管理和安全性以及通信开销方面,将每个服务建模为一个过程的想法是一个更复杂的问题.OSGi更简单,更快捷.话虽如此,使用OSGi远程服务很容易将服务转入和转出流程障碍,所以我相信它是微服务实现技术的不错选择. (2认同)

Answer 2

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

在我看来,Jigsaw结合了对JDK中可行的东西和之前与SUN和OSGi家伙之间糟糕关系的妥协.也许它会附带Java 8,但我们必须拭目以待.

如果您在典型的企业环境中工作,OSGi并不是万能的,您需要熟悉类加载的工作原理,因为许多着名的库(看着你,Hibernate)对类可见性的假设不再有效在OSGi内部.

我喜欢OSGi,但我不会尝试将它改装到现有系统.我还要权衡绿地开发方面的优缺点 - 我建议您查看简化OSGi生活的Apache或Eclipse产品,而不是自己动手.

如果你没有做OSGi,那么如果你想出一个依赖于同一个库的不同版本的系统,你就不幸了 - 所有你能做的就是尽量避免这个问题,尽管需要多个版本的图书馆对我来说似乎是一种"气味".

@Mara说有坏血是不公平的.毕竟,大约12年前,Sun是OSGi的共同创造者之一(JSR 8).在甲骨文收购前大约一年,Sun还作为正式成员重新加入了OSGi联盟.他们还在Oracle之前的OSGi上开发了相当多的软件.最明显的例子是Glassfish.但是,可以公平地说,Sun/Oracle和OSGi的某些人之间存在摩擦. (6认同)

Answer 3

我喜欢你用"角落案例"来描述当前的情况.

JAR文件规范存在缺点,可能导致在某些极端情况下进行名称空间解析和类加载问题

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

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

而且,作为奖励,它会让你有机会做很多很酷的事情.想象一下,在演示过程中,无需流量丢失即可无缝升级身份验证模块,以支持OAuth ......创建内容时,它突然变得更加快乐!