Proposal to revise forest graph and integration practices for JDK 9

Phil Race philip.race at
Thu Dec 5 10:10:32 PST 2013

I don't think what Artem said is quite correct. SQE may not do manual 
But the integrator certainly does.  The final steps of our integration 
has always included certain manual tests (applets, SwingSet, Java2Demo) on
all the platforms (Windows, Linux, Solaris and now Mac) on the final 
built bits.
We will need to maintain that process.

Whilst hotspot and language changes may need to coordinate to be in the
same place sooner rather than later there is no such need for client 
So no benefit accrues from a shared forest there.


On 12/5/2013 9:09 AM, mark.reinhold at wrote:
> 2013/12/2 16:14 -0800, joe.darcy at
>> On 12/02/2013 04:52 PM, Lana Steuck wrote:
>>> On 12/02/2013 11:38 AM, mark.reinhold at wrote:
>>>> That's no doubt a good thing, but are we confident that we'll be able
>>>> to do such an integration every week, including any necessary manual
>>>> testing of client code? If not then it seems we need a separate
>>>> client forest that feeds into the dev forest after appropriate
>>>> testing, just like the HotSpot forests. - Mark
>>> It seems that it would depend on SQE resources. If SQE could perform
>>> manual client testing of the pre-integration build weekly, then we
>>> could do weekly integrations of jdk9-dev.
>> A few more thoughts on client library code.
>> ...
>> My strong preference is to start JDK 9 *without* a forest dedicated to
>> client libs changes and only add such a forest if that arrangement
>> proves unworkable in practice. Fewer forests means testing efforts can
>> be more focused.
> Based on what Yuri and Artem said elsewhere in this thread, it sounds
> like the manual pre-integration testing of client code is light enough
> to support this approach, so let's go with it.
> - Mark

More information about the jdk9-dev mailing list