所以截至昨天早上我还没有找到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地狱的人!)