Proposal to revise forest graph and integration practices for JDK 9

Joe Darcy joe.darcy at oracle.com
Sun Nov 24 09:41:23 PST 2013


On 11/23/2013 2:08 PM, Omair Majid wrote:
> * Joe Darcy <joe.darcy at oracle.com> [2013-11-23 11:35]:
>> The current arrangements of sets of integration forests for a JDK
>> platform release, like JDK 8, impose high overheads on development.
>> I'm proposing we use an alternate forest arrangement for JDK 9 that
>> will dramatically reduce the propagation time of fixes across the
>> set of forests. More details below.
> I think this is a huge step forward. Thank you for proposing this.

Thanks; I've wanted to help address this situation for a while.

>
>> * The dev forest conceptually replaces TL and hosts all
>> libraries-related changes. When the sources in dev are in a
>> known-good state, that state can be integrated to master. This
>> integration cycle would happen at least weekly. In a change from
>> current practice, HotSpot changes would be integrated into dev and
>> *not* into master. All other team forests would also integrate into
>> dev rather than master.
> Would forests for specific projects (as an example, lets say jigsaw)
> also follow this pattern of pulling from and merging to dev ?

I would expect Jigsaw to follow a model more like Project Lambda: the 
project-specific forest lives on its own for an extended period of time 
(months or longer) and syncs in changes from the corresponding JDK dev 
(or master). When the project has sufficiently matured, there is large 
sync from the project to dev. From that point forward, there is 
diminished activity in the project forest as activity related to the 
project shifts to happening directly in dev.

>
>> * Coordinated HotSpot + other component fixes would *both* get first
>> pushed through the HotSpot forest.
> With the benefit of hindsight, I wonder why it wasn't this way to start
> with :)

The integration structures described earlier have been in place since at 
least JDK 5, circa 2003 - 2004. (We've actually used distributed version 
control for the JDK since that time too; although it was the Sun 
teamware product rather than Hg.) Historically, I believe there were 
concerns about being able to do proper testing for cross-component 
fixes, but I think solving that challenge would be an improvement over 
the current state of affairs.

-Joe



More information about the jdk9-dev mailing list