Peter品评JSR277

Peter对于JSR 277是极度的关注，毕竟JSR 277和OSGi在实现的目标上具备了那么多的共同性，从98年开始，Peter就希望能加入JSR 277 JCP Group，但是被拒了，JSR 277基本完全是SUN在主导的，经过这么多年了，JSR 277的草稿终于是发布出来了，Peter在对JSR 277做了Review后特意写了篇Blog做了评价，总结而言，Peter认为JSR 277 just like a toy,JSR 277并没有吸取OSGi在这8年模块化方面的教训和经验，在模块的一致性校验、可选性、分离包机制等等方面都缺少足够的考虑，原文见：
http://www.osgi.org/blog/2006/10/jsr-277-review.html
作为OSGi的主席，Peter在Java规范的模块化和动态化绝对是具备足够的发言权的，他对于JSR 277过分简单的解决规范的模块化的策略感到很遗憾，JSR 277采取的是一种类似OSGi Require-Bundle的机制来形成模块，模块在JSR 277中定义为以Module的形式来进行部署，对于Module的信息如(引用的模块、对外暴露的包和资源文件等)则在MODULE-INF/METADATA.module中进行描述，每个标准的JSR 277模块需要有一个Main类，在这个类中需要有一个Main方法，在触发Main方法前，环境必须首先检测此模块所引用的模块是否已OK，如没有OK的话是不会启动的，从这已经反应出了，JSR 277是不支持动态化的，在JSR 277中模块不支持卸载，同样，在运行期是无法改变模块和加载新的模块的，必须在停了VM后才能进行这些操作，OK，也许对于不是那么看重动态性的应用来讲这点没那么重要，但是JSR 277在规范的模块化上做的实在是过于简单，考虑欠周，为什么这么说呢？
按照Peter说的几点来看看：
一致性校验
JSR 277中模块是通过直接引用其他的模块来形成依赖的，但它仅仅以模块名以及版本来构成依赖，并未去解决一致性的问题，这样说很晦涩，举例来说：
有A、B、C、D四个模块：
A 引用 B 1.0，C 1.0
B 1.0 引用 D 1.1
C 1.0 引用 D 1.0
在JSR 277中这样的情况下会出现A同时可看到D 1.0和1.1两个版本下的类，自然就很容易产生冲突，这个相信大家早就对java中引用包冲突的现象恨之入骨了....
可选性
可选性这个显然是因为JSR 277不支持动态性而形成的，Peter举了个例子是这样的：
一个类可被作为Ant Task、Eclipse Plugin等多种形式来运行，在JSR 277为了让这个类可以被各种各样的方式运行，不得不把相关的包全部导入，而在OSGi中则不需要，可以通过optional的方式来动态的去加载所需要的包，这点对于大型应用而言是比较重要的。
未提供包共享的机制
JSR 277不是采用包共享的机制来实现模块之间的类的共享，而是通过模块引用的方式来实现，这个带来的问题很明显，平白的去多引用了不需要的东西，而JSR 277采用模块引用这样的方式也让我们看到JSR 277并没有充分考虑如何实现模块之间的互动。
Peter最后提及他非常不看好JSR 277，他觉得如果JSR 277能够通过的话要么是因为各大厂商根本就不关心，要么就是因为SUN在这个规范中的主导地位。

上面几点是Peter所言，个人认为JSR 277作为模块化的规范，应该为模块的定义、设计、开发、部署都做到足够的考虑，而以目前JSR 277来看，在模块通信机制、模块管理上缺乏完整的定义，而这些是一个模块化的规范中最为根本和重要的东西，而OSGi中则提供了Bundle contains multiple components,Service-Oriented Component Model以及强大的动态化的Bundle管理API来实现模块的通信和管理，至少从目前看来，OSGi的设计思想仍然是模块化设计系统的一种很好的指导思想。

ps: 在明年的Eclipse大会上将会专门有OSGi的专题部分，而且在看Eclipse 3.3的feature中可以发现Eclipse 3.3很重视对于基于OSGi开发系统更好的支持 :)