Proposal to revise forest graph and integration practices for JDK 9

[Andrew]

----- Original Message -----

snip...

> 
> So, I'd like to suggest that jdk9/dev replaces the equivalent of jdk9/tl,
> jdk9/awt, jdk9/swing, jdk9/2d, jdk9/build, jdk9/deploy, jdk9/l10n,
> jdk9/swing, nashorn/jdk9 in one go. If long term features require a
> throw-away integration forest, create one as you need it for as long as you
> need it, integrate and close that forest.
> 

+1

As a non-Sun/Oracle person, I've never seen the point in all these separate
forests and my experience of working with people new to OpenJDK is it makes
it very confusing.  This is especially the case with 2d/awt/swing and
I don't recall ever seeing any activity in l10n or deploy (what is that?)

I'd opt for just having a lib tree and a hotspot tree which then integrate
into a master.

> I don't have an opinion on pruning hotspot forests (yet;), but you may want
> to consider where a fix containing changes both for hotspot and libraries
> would need to go to if you retain the current structure - gc? rt?
> hotspot-dev? hsx25? main? comp?

Again, never understood why we need so many trees for HotSpot and it's not clear
where a fix will go.

> 
> > (Conceptually, in this model a separate master forest is not strictly
> > needed since the known-good states could be indicated using a mechanism
> > like Hg tags. However, while adjusting to the new model and to allow for
> > fixes directly to master in exceptional circumstances, I'm proposing a
> > physically separate master forest be retained. The distinct URL of master
> > will also clearly indicate known-good states of the source code.)
> 
> One of the not very useful things we did for 7u was to keep a separate master
> forest.
> 
> Considering the real benefits of a master forest [1], and the real drawbacks
> when it's being used with a rapidly changing tree underneath [2], I'd
> suggest you drop the master forest for JDK 9.
> 

I'd assumed it was needed for some internal Oracle stuff but if it's not, drop
it by all means.

> One thing missing from the proposal is jdk9 repository layout within the
> forests. I think that this may be good opportunity to simplify the current
> historically grown structure, for example by folding the nashorn and
> langtools repositories together, as well as corba, jaxp, jaxws and jdk.
> 

+1000

I've not come across the issues Joe mentions much.  By far the biggest issue that
comes to mind when I think of forest layouts is the pointlessness of separate
CORBA, JAXP and JAXWS repositories (not had anything to do with nashorn yet).

There's huge duplication in the build infrastructure between CORBA and JDK (for 7;
I can't really tell with all this new build system stuff because all the old stuff
still seems to be there too, making things even more confusing).  At least with 7,
if you change JAXP, the JDK build doesn't pick it up and I had to manually force
it onto the bootclasspath to test changes.

So yes, langtools (for bootstrap), HotSpot & JDK only, I'd say.

> cheers,
> dalibor topic
> 
> [0] Caffeine is fascinating:
> https://en.wikipedia.org/wiki/Effect_of_psychoactive_drugs_on_animals#Spiders
> ;)
> [1] Someone could build from it without having to learn about tags. Yay! ;)
> [2] Change means something is going to get borken somehow sometime,
> inevitably. The 'unbreakable' 7u master broke a few times, each time
> triggering an epic amount of e-mail, because the fix wasn't necessarily as
> simple as 'let's just revert this one breaking change on -dev and tag a new
> build', since we had to deal with the added complexity of having a master
> forest that was never supposed to be broken, and yet there it was, broken
> again. I may misremember some of it now, because the way the brain works
> around traumatic experiences ;)
> 
> --
> Oracle <http://www.oracle.com>
> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
> Oracle Java Platform Group
> 
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
> 
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
> Geschäftsführer: Jürgen Kunz
> 
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
> 
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07