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