Merges of code lines between releases would be halted after JDK 9 is initialized from JDK 8

With developers ready to move from building Java Development Kit (JDK) 8 to JDK 9, Oracle's chief Java executive proposes to restrict merges between the two code lines.

In an email posted to an OpenJDK mailing list Monday afternoon, Mark Reinhold, chief architect of the Java platform group at Oracle, noted changes to JDK 8 (due in early 2014) are ramping down, while the JDK9 "forests" -- that is, a directory tree or set of directories -- will be open soon. Developers now must cope with managing changes to go into both releases, Reinhold said.

The general rule has been that changes should go into the development release first before they're backported to earlier releases. However, it doesn't make much sense during the endgame of a feature release, since the release in preparation (JDK 8 in this case) will be more thoroughly tested during this period than the newly started successor. This would also slow down work on the endgame release since changes would go through its successor first.

Previously, up to JDK 7, there was no policy for handling parallel change. A developer would usually push a change to the release in which it was first required, while someone from the Sun/Oracle release engineering team would perform semi-automatic merges from the endgame version to the successor release until those merges became impractical. Developers would then be asked to push changes to both releases; bug-database queries would be used to help ensure changes wound up in the correct release.

"This approach has never scaled very well," Reinhold said. "It requires every one of the hundreds of developers contributing to the endgame release to monitor whether semi-automatic merges are still being done, then change their integration workflows as soon as those merges stop."

To simplify the release-endgame process, Reinhold is proposing that JDK 9 development forests be initialized from a specific build of JDK 8. "After that build, merges between the two code lines will not be permitted. A developer who pushes a change into JDK 8 must also apply that change independently to JDK 9, if that change is applicable to JDK 9."

Reinhold hopes the change will clear up the process. "The only downside I can see is that it won't be possible to build JDK 8 GA [general availability] from a JDK 9 forest since the latter will fork from JDK 8 prior to GA. It's somewhat convenient -- and kind of cool -- to be able to do that, but I think it has more aesthetic than technical value. You can't build a JDK 7 Update release from a JDK 8 forest; this situation is no different."

Based on Java Standard Edition 8, JDK 8 is set to support Project Lambda, to make it easier to write code to run on multicore processors. A preview build already has been available. The subsequent Java SE 9 release, expected to debut in early 2016, is set to offer Project Jigsaw, featuring modular capabilities for Java.