| 就在开发人员们准备由Java开发工具包(简称JDK)8向JDK 9迈进之际，甲骨文公司首席Java高管建议限制对这两个版本的代码行进行合并。 在本周一下午发往OpenJDK的一封邮件当中，甲骨文公司Java平台部门首席架构师Mark Reinhold指出针对JDK 8(将于2014年年初到期)的变动将快速缩减，而JDK 9的“forests”——也就是一种目录树或者目录集机制——则将很快开放。现在开发人员必须应对相关管理变化、从而顺利与这两个版本进行对 接，Reinhold表示。 一般来说，变动通常需要首先在开发版本中进行测试，而后才会回迁到较早版本当中。不过这一规则对于即将寿终 正寝的版本来说并不太适用，因为筹备中的版本(也就是目前JDK 8的情况)在此期间将更多地接收全方位测试、而不再像继任者那样以新功能与新特性作为主要诉求。由于各类调整都会在继任版本中体现，所以即将淘汰的上代版 本在发布速度上也会比较缓慢。 在此之前，也就是JDK 7，甲骨文并不提供处理并行变动的政策。开发人员通常会在接到请求之后将变动纳入当前版本中，来自Sun/甲骨文版本工程团队的人员则以半自动方式将前代 版本与继任版本进行合并——某些不切实际的合并请求将不会被采纳。其后，开发人员需要将变动推送至新旧两个版本当中;漏洞数据库查询机制则被用于确保不同 变动能够作用一正确的对应版本。 “这套方案一直没能取得理想的效果，”Reinhold告诉我们。“它要求数百位开发人员始终关注并调整前代版本，从而监控半自动合并流程是否正常进行;一旦合并中止，他们就需要马上对集成工作流进行调整。” 为了简化前代版本的发布流程，Reinhold建议将JDK 9的开发forests以JDK 8的特定build初始状态作为起点。“在这套build之后，我们不再允许对两个版本的代码行进行合并。向JDK 8提交变动的开发人员还需要独立将该变动交付至JDK 9——前提是这项变动适用于JDK 9。” Reinhold希望此举能够让整个 流程更加简洁明了。“我能想到的惟一缺点就是开发人员无法再通过JDK 9来创建JDK 8通用版了，这是因为前者将优先考虑与JDK 8的兼容性而非JDK 8通用版。如果能做到这一点当然很方便也很酷，但我认为它最多能带来某种成就感、而不是实际层面的技术价值。大家无法通过JDK 8创建JDK 7更新版本;现在的情况与当时并没有什么区别。” 以Java Standard Edition 8为基础的JDK
8能够支持Lambda项目，从而使其更易于编写运行在多核心处理器中的代码。目前已经有一套预览版本可供使用。随后的Java SE
9版本预计将于2016年年初面世，能够通过Jigsaw项目为Java带来模块化功能机制。 |
