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地狱东西的人！）