发新话题
打印

OSGi Java模块化框架的另类进化

OSGi Java模块化框架的另类进化

【IT168 评论】我们曾不只一次的听到2010年将是Java模块化的一年的言论;也晓得目前为Java提供模块化的OSGi正在遭到IBM和Eclipse基金会的大力支持。但作为实现Java模块化使用的基础框架,OSGi似乎并不完美;我们经常能听到关于OSGi过于复杂的抱怨。
  从个人的角度,我以开放的心态去理解OSGi。令人失望的是,我发现它的规则非常复杂而且是低阶的(low-level),对于大少数企业 Java 环境,需要对其进行许多改善/缩写的工作,才干让它更容易被人理解。对于大少数实际的企业需求,它又显得功能过于强大。比较而言,Jigsaw 感觉更“洁净”,以 Java 为中心,紧凑而且易于理解。
  说实话,这种抱怨让我有点困惑。jeanjack我来假设一下,如果OSGi 如今并不存在,有人给我一项义务,为Java 平台设计一个新的模块系统,那么对于这个模块系统的最合理的需求集合将直接指向OSGi,因为OSGi的设计目的可能是满足我们需求的最复杂的解决方案。
  是不是我的想象力不够?或者这不过是爱因斯坦剃刀原理(事物应尽可能复杂而不是更复杂)打败奥卡姆剃刀原理(如无必要,勿增实体)的又一个实例?
  另外,我认可OSGi 初看并不是那么复杂这一说法,尤其是你不理解它为什么会是如今这样的时候。

在这篇文章中,我将依照上述的那个假设,从零末尾设计OSGi 系统。当然许多细节问题在这里我不能一一讲述。下面切入正题,为什么OSGi 成为如今这个样子?我们一起看看OSGi不算漫长但足够复杂的进化(这种进化是积极的,因为它为解决业界实际存在的问题而生)。
jiyizhen-buy.com颈椎保健枕太空记忆枕 igerl.com歌瑞尔内衣

TOP

发新话题