Java模块化之争

一、JCP组织

1998年，在sun公司推动下，成立了JCP（Java Community Process）组织，这个组织负责制定Java技术标准，发布技术标准的参考实现（RI）和用于检验标准的技术兼容包（TCK）。有数以百计的公司、组织、个人参与JCP组织，监督并维护Java 标准的制定。参与者中的16位代表组成了JCP执行委员会（Java SE/EE两个方向的委员会）。由委员会对提交给JCP的天进行投票表决。

JCP允许任何组织和个人对Java的演进路线提出建议，这些建议在审查立项后会以JSR（Java Specification Requests）的形式，形成正式的规范文档。在经过专家组审核和执行委员会投票通过后，这些JSR文档就将成为正式的Java技术规范。比如J2EE、EJB、JSP、JDBC等规范都由对应的JSR孵化而来。甚至连JCP本身的组织和运作都有特定的JSR文档进行定义。

二、OSGi联盟

OSGi（Open Service Gateway Initiactive，开发服务网关）实际上是源于JSR-8（Open Service Gateway specification，开放服务网关规范），由Sun发起并主导（还有IBM等公司）、在1999年3月提交到JCP的。主要是定义了不同设备之间服务互相依赖和调用的交互接口。因为1999年，Java2刚发布不久，互联网刚刚兴起，Java主打支持各种移动设备、嵌入式设备、智能家电。

同年5月（1999年5月，提交之后2个月），Sun就撤回了JSR，主要是因为发起者希望另外建立一个独立于JCP的组织来发展运作这份规范，让更多不适合参与到JCP的设备厂商能够参与OSGi的规范制定。1999年独立于JCP的OSGi联盟成立，并在2000年发布了OSGi规范的第一个版本：OSGi R1.0

三、分歧开始

OSGi的R1.0~R3.0主要领域依然是移动和嵌入式设备上，跟Sun相处非常和谐，但是从R4.0开始，OSGi尝试进入JavaSE/EE领域，于此同时，各个成员在发展和商业选择上也有分歧，主要是IBM和Sun争夺OSGi的主导权。2006年Sun离开了OSGi。所以OSGi保持原有领域的同时，开辟了Java主流领域。Eclipse成功应用了使用OSGi架构的Equinox框架，赢得广泛关注，Java支持模块化势不可挡，Sun不得不重视起来。

四、战场转移

2006年10月，Sun提交JSR-277规范提案（Java模块化系统），但是它是一个全静态的模块化规范，没有任何关于动态化的考虑，这样模块就无法在运行时安装、更新和卸载，也就不存在hotswap了，相对于OSGi是一大退步。为了与OSGi竞争，Sun决定力挺JSR-277，把OSGi引到JCP中来。因为在JCP中Sun有很大影响力，他是发起者，在执委会中拥有无需选举的无限期执委会投票权，其他15个执委席位三年选举一次。IBM将OSGi R4.1提交到JCP成为JSR-291（JavaSE动态支持组件）与JSR-277对抗，规范之争的战场重新回到JCP中。

五、一意孤行

2007年5月，OSGi通过投票就应该是正式的Java规范，但是Sun依然在2007年7月提交的JSR-316（JavaEE6规范）中写道：为了更好的支持这个平台JavaEE6在扩展性方面的目标，应该有一个更好的模块化概念，这项工作正由JSR-277实现，目标平台是JavaSE7，因此我们将推迟任何可能与JavaSE7冲突的技术规范。这个描述就是压制OSGi的。因为Sun实质性地控制着JDK的发展，所以OSGi无能为力，JavaSE6期间没有任何更新。JSR-316之前，Sun还提交了一个JSR-294，要在Java语言和JVM的层面上对模块化进行支持。单从技术上讲，平台内支持比OSGi在平台之上支持模块化要好很多，但是JCP一般不同意修改语法。

虽然JSR-294和JSR-277都被废弃在预览版，但是Sun早已在OpenJDK偷偷启动了Jigsaw项目，目标是就是作为JSR-294的参考实现（RI）。Sun如此一意孤行，会导致使用Jigsaw的程序无法在其他公司提供的JDK上运行，损害Java语言的根基。除非JCP重新激活JSR-294，或者再提交一个JSR并在JCP通过。Java7和Java8两度爽约，2012年7月网站宣布Jigsaw在Java9中发布。

六、修成正果

Java版本每期都推迟，2017年9月发布了Java9，新特性中包含模块化。但是Jigsaw不能不正视OSGi的影响力，于是建立了一个Penrose子项目，让Jigsaw与OSGi相互操作。