De aankomende versie 8 van Java dreigt incompatibel te worden met opvolger 9. Oracle zet zijn developmentplannen uiteen voor de twee toekomstige versies, waarvan de eerstkomende begin komend jaar verschijnt.

Java-hoofdarchitect Mark Reinhold stelt nu een code-freeze in voor wat betreft de build van JDK 8 (Java Development Kit) op basis waarvan dan verder wordt gewerkt aan versie 9. Dit moet het afrondingsproces voor een nieuwe release van Java vereenvoudigen. "Na die build zijn samenvoegingen tussen de twee code-lijnen niet meer toegestaan", aldus de Oracle-topman die bij Sun al over Java ging.

Versie 8 bijna af, versie 9 bijna begonnen

Hij doet dit voorstel in een post op de mailinglist voor OpenJDK. "De snelheid van verandering in JDK 8 neemt af, en de JDK 9 forests worden binnenkort geopend. Hoe gaan we om met veranderingen die in beide releases moeten komen totdat JDK 8 uitkomt?" Tot op heden geldt de algemene regel dat veranderingen, zoals nieuwe functies, voor Java eerst worden opgenomen in de huidige development-release.



Daar worden ze in een paar testrondes beproefd om vervolgens te worden doorgevoerd in voorgaande releases. "Deze regel is niet echt zinnig gedurende de slotfase van een feature-release", argumenteert Reinhold. "Aangezien de release in voorbereiding (JDK 8 in dit geval) veel grondiger getest wordt gedurende deze periode dan zijn net opgestarte opvolger (JDK 9)."

Vertraging voor ontwikkelwerk

Naast het argument van betere testing is er de impact op het ontwikkelwerk. Het doorvoeren van wijzigingen in JDK 8 zou voor vertraging zorgen, "aangezien alle veranderingen eerst door zijn opvolger heen moeten gaan". Versie 8 heeft al vertraging opgelopen vanwege het dichten van vele gaten in versie 7. Tot en met die huidige had Oracle (en daarvoor Java-schepper Sun Microsystems) geen beleid voor het beheer van dergelijke parallelle ontwikkeling.

Normaliter zou een developer een wijziging eerst doorvoeren in de release waarvoor het is vereist, schetst Reinhold. Daarna zou iemand van het release-team semi-automatische samenvoegingen (merges) uitvoeren om de release die bijna af is gelijk te krijgen met de opvolger, die nog volop in ontwikkeling is.

Die merges zijn op een gegeven moment niet meer praktisch vanwege de flinke verschillen (divergentie) die inmiddels zijn opgebouwd. "Elk van de honderden developers die bijdragen aan de endgame-release moet monitoren of semi-automatische merges nog wel worden uitgevoerd, en zij moeten hun intergratie-workflows aanpassen zodra die merges worden stopgezet."

Voor elke versie apart indienen

Met ingang van JDK 8 moet dat anders, pleit Reinhold. De ontwikkel-'bossen' voor JDK 9 worden aangemaakt op basis van een specifieke build van versie 8. Merges zijn daarna verboden. Een developer die een wijziging doorvoert in 8 moet die ook apart toepassen voor versie 9, "als die verandering van toepassing is op JDK 9".

Daarbij moet de developer wel extra werk verrichten voor die tweede patch. Door dit voorstel dreigt gebrek aan terugwaartse compatibiliteit, merkt Webwerelds Amerikaanse zustersite InfoWorld op. Niet alle nieuwe functies in de ene Java-versie komen namelijk gegarandeerd in een andere (voorgaande of volgende) versie terecht.

Reinhold ziet maar één nadeel: dat het niet mogelijk is om een definitieve release van JDK 8 te maken op basis van een JDK 9-forest. "Het is gemakkelijk - en enigszins cool - om dat te doen, maar ik denk dat het meer esthetische dan technische waarde heeft." Een Java-developer van SAP die reageert op dit voorstel haalt mogelijke downport-problemen aan. JDK 8 moet in maart uitkomen, en opvolger 9 staat gepland voor begin 2016.