OSGi、Java Modularity 和 Jigsaw
所以从昨天早上开始，我甚至不知道OSGi是什么。OSGi只是一些流行语，我一遍又一遍地看到，所以我终于留出一些时间来梳理它。
这实际上看起来很酷，所以我想首先声明（为了记录在案）我在任何方面都不是反OSGi的，也不是一些“OSGi抨击”的问题。
归根结底，OSGi似乎已经 - 基本上 - 解决了Java模块化的JSR 277，它认识到文件规范存在缺陷，在某些极端情况下可能导致命名空间解析和类加载问题。OSGi还做了很多其他非常酷的东西，但据我所知，这是它最大的吸引力（或其中之一）。JAR
对我来说 - 作为一个相当新的（几年现在）Java EE开发人员，我们正处于2011年，目前生活在Java 7时代，并且这些类加载问题仍然存在，这绝对是令人难以置信的;特别是在企业环境中，一个应用程序服务器上可能有数百个JAR，其中许多JAR依赖于彼此的不同版本，并且所有JAR都同时运行（或多或少）。
我的问题：
尽管我对OSGi很感兴趣，尽管我想开始学习它，看看它在哪里/是否对我的项目有用，但我只是没有时间坐下来学习那么大的东西，至少现在是这样。
那么，当这些问题出现时，非OSGi开发人员该怎么办呢？目前存在哪些Java（Oracle/Sun/JCP）解决方案（如果有的话）？为什么拼图是从J7上剪下来的？Jigsaw明年将在J8中实施的社区有多确定？是否有可能为您的项目获取Jigsaw，即使它还不是Java平台的一部分？
我想我在这里问的是恐慌，阴谋和面部表情的结合。现在我终于明白了OSGi是什么，我只是不明白“像Jigsaw这样的东西是如何花了20多年的时间才实现的，然后又是如何从发布中得到罐头的。这似乎是根本性的。
而且，作为一名开发人员，我也很好奇我的解决方案是什么，没有OSGi。
另外，注意：我知道这不是一个“纯编程”类型的问题，但是在你们中的一些人让鼻子弯曲变形之前，我想声明（再次，为了记录）我故意把这个问题放在SO上。那是因为我对我的SOers同胞只有最大的尊重，我正在寻找一些我每天潜伏在这里的“IT之神”的架构级答案。
但是，对于那些绝对坚持要用一些代码段来支持SO问题的人来说：
int x = 9;
（感谢任何能够权衡这个OSGi /Jigsaw/classloader/namespace/JAR地狱般的东西的人！
