自JDK 8开始出现的跨版本代码行合并机制将在JDK 9之后宣告中止
就在开发人员们准备由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带来模块化功能机制。
原文链接：http://www.infoworld.com/t/java-programming/oracle-limit-backward-compatibility-java-9-java-8-231967
