选择Impala和OSGi

Question

我一直在为我公司的软件调查OSGi ，但最近建议我们去看看Impala。 根据其网页， Impala是“基于Spring框架的基于Java的Web应用程序的动态模块框架”。

一目了然，看看这篇关于差异的博客文章 ，我可以看到的关键差异是Impala比OSGi简单，不管理第三方组件的版本化，并且使用/知道的广泛使用（我看不到）关于Stack Overflow的一个问题。

我想知道那些对Impala和OSGi有直接经验的人（即那些比阅读博客文章和在线文档更深入调查过的人），对于两者之间的实际差异有更深入的了解，和/或关于什么类型的每个项目可能或多或少都适合。

编辑：将Springsource Slices包含在比较中可能也很有趣，尽管它还是早期的原型。 一目了然，它似乎只适用于DM Server。

Answer 1

在模块之间进行受控共享时，Impala的模块化方法非常薄弱。 问题是Impala仍然遵循旧的J2EE风格的分层方法来进行类加载。

任何人都可以编写一个模块系统来限制跨模块的类的可见性。 困难的部分是如何重新引入模块之间的依赖关系，以便另一个模块可以看到来自一个模块的特定类和接口。 在OSGi中，我们通过导出和导入包来实现这一点，因此我们有一个非层次的依赖图。

在Impala中，如果要查看另一个模块中的类，则模块必须是该模块的子级或后代。 也就是说，模块只能看到自己的类和它们的祖先类。 现在，如果您想与兄弟模块共享一些类（例如您使用的库），那么您必须将该库移动到共享祖先的类路径中。 在最坏的情况下，您必须将其移动到根模块。 现在，所有其他模块都可以看到该库是否需要它们！ 实际上，如果另一个模块想要使用不同版本的库，则会阻止它们这样做。

如果您只是在每个使用它的地方都有一个库的副本，那么您就无法使用该库的模块相互通信。 当他们尝试在彼此之间传递对象时，他们将获得ClassCastExceptions。

如果两个Web应用程序需要使用相同的库，则类似的问题是J2EE中固有的。 通常，J2EE开发人员只是复制库，但这会创建无法相互通信的“孤岛”应用程序。 它根本不是构建模块化软件的方法。

史蒂文的观点似乎也很恰当。 据我所知，除了作者之外，没有人使用Impala。

Answer 2

在我看来，没有比较。 OSGi是一个成熟的框架，已经存在了10年，是实现当今大多数Java容器的基础。 OSGi的应用越来越多，有可用的书籍，是的，人们在Stack Overflow上谈论它！

Impala甚至没有达到稳定版本，似乎是一个单人项目，尽管他现在要求其他开发人员。

所以，这取决于你的标准。 如果您正在调查技术的兴趣，那么我没有看到任何与Impala编写内容的问题。 如果您希望将公司的未来产品建立在其上，那么我认为这将是专业疏忽。