我一直在为我公司的软件调查OSGi，但最近有人建议我看看 Impala。根据其网页，Impala 是“基于 Spring 框架的基于 Java 的 Web 应用程序的动态模块框架。”
一目了然，看看这个 blog post 关于差异，我可以看到的主要差异是 Impala 比 OSGi 更简单，不管理第三方组件的版本控制，并且远没有被广泛使用/知道（我在 Stack Overflow 上没有看到一个关于它的问题）。
我想知道那些对 Impala 和 OSGi 有直接经验的人（即那些比阅读博客文章和在线文档更深入地研究它的人），是否对两者之间的实际差异有更多的见解，和/或关于每个项目可能或多或少适合哪些类型的项目。
编辑：将Springsource Slices 包含在比较中也可能很有趣，尽管它仍是早期原型。乍一看，它似乎只在 DM Server 中工作。
【问题讨论】：
在我看来，没有可比性。 OSGi 是一个已经存在 10 年的成熟框架，是实现当今大多数 Java 容器的基础。 OSGi 的采用率越来越高，有可用的书籍，是的，人们在 Stack Overflow 上谈论它！
Impala 甚至还没有发布稳定版本，而且似乎是一个单人项目，尽管他现在正在寻求更多的开发人员。
所以，这取决于您的标准。如果您出于兴趣而研究技术，那么我认为使用 Impala 编写内容没有任何问题。如果您希望以此为基础开发您公司的未来产品，那么我认为这是专业疏忽。
【讨论】：
Impala 的模块化方法在模块之间的受控共享方面非常薄弱。问题是 Impala 仍然遵循旧的 J2EE 风格的分层方法来加载类。
任何人都可以编写一个模块系统来限制跨模块的类的可见性。困难的部分是如何重新引入模块之间的依赖关系，以便一个模块中的特定类和接口可以被另一个模块看到。在 OSGi 中，我们通过导出和导入包来做到这一点，因此我们有一个非分层的依赖关系图。
在 Impala 中，如果您想查看另一个模块中的类，那么您的模块必须是该模块的子模块或后代。也就是说，模块只能看到它们自己的类和它们祖先的类。现在，如果您想与您的兄弟模块共享一些类（例如，您都使用的库），那么您必须将该库移动到共享祖先的类路径中。在最坏的情况下，您必须将其直接移动到根模块。现在，所有其他模块都可以看到该库，无论他们是否愿意！事实上，如果另一个模块想要使用不同版本的库，他们会被阻止这样做。
如果您只是在每个使用该库的地方都有一个库的副本，那么您就无法让使用该库的模块相互通信。当他们试图在彼此之间传递对象时，他们会得到 ClassCastExceptions。
如果两个 Web 应用程序需要使用同一个库，J2EE 中就会存在类似的问题。通常，J2EE 开发人员只是复制库，但这会创建无法相互通信的“孤岛”应用程序。这根本不是构建模块化软件的方式。
Steven 的观点似乎也很中肯。据我所知，除了作者之外，没有人在使用 Impala。
【讨论】：