Zeit für Octoduke

JEP 369: GitHub wird designierte Hosting-Plattform für Java

Dominik Mohilo

© Shutterstock / Ivan Hoermann

Im Sommer 2018 erblickte Projekt Skara das Licht der Welt. Die Aufgabe: Alternativen für Mercurial als Javas Versionskontrollsystem (VCS) finden. Das Ergebnis ließ nicht lange auf sich warten und hieß (natürlich) Git. Der nächste Schritt, nämlich die passende Hosting-Plattform für die Repositories zu wählen, ist Bestandteil von JEP 369. Der Name der Plattform ist wenig überraschend…

Die Geschichte um Java und dessen mögliches Abwenden von Mercurial als Versionskontrollsystem (VCS) begann schon lange vor der Gründung von Projekt Skara, in dessen Rahmen Alternativen gesucht wurden. Mercurial galt schon seit einiger Zeit als veraltet und (besonders im Vergleich zu gewissen Alternativen) zu langsam. Wenig überraschend war es also, dass es bei Projekt Skara weniger um das Ob als vielmehr um das Wohin in Sachen Umzug ging. Schnell stellte sich heraus, dass wohl Git das „perfect Match“ für die Java Repos sein könnte, schon allein aus Gründen der Performance, wobei auch die Verbreitung von Git mittlerweile beeindruckende Ausmaße angenommen hat.

Im Juli dieses Jahres, also fast ein Jahr nach der Gründung von Projekt Skara, folgte mit dem Java Enhancement Proposal 357 die JEP-gewordene Ankündigung für das Ende der Suche: Git hatte sich (trotz der Vorbehalte einiger Java-Experten wie Martijn Verburg) als Versionskontrollsystem der Wahl durchgesetzt. Dies lag vor allem an der radikal anderen Funktionsweise von Git im Vergleich zu Mercurial:

Beim Verschieben einer Datei erstellt Mercurial eine komplette Kopie der ursprünglichen Datei und speichert diese. Verschiebt man nun viele Dateien, wie bei der Entwicklung eines JDKs (gerade für JDK 9 wurden wegen des neuen Modulsystems viele Dateien verschoben), kommt es dabei zu extrem großen Speichermengen. JDK 8 hatte eine Größe von 412 Megabyte, JDK 9 war schon auf 800 Megabyte angewachsen und JDK 10 hat über 1,5 GB. Joe Darcy, der Initiator von Projekt Skara und Stakeholder von JEP 357, berichtet, dass es mit Git besser werden dürfte:

On some git imports of the JDK we’ve done internally, we ended with a git repo size of recent JDK sources of around 300 MB, roughly 5X smaller. That 300 MB includes all the JDK changeset history and tags, etc.

Für große Projekte wie das JDK ist die Versionskontrolle, also das Source-Code-Management (auch als SCM bekannt), ein wichtiger Teil der Infrastrukturverwaltung und des Workflow-Prozesses. Das traditionell für das JDK und Satelliten-Projekte eingesetzte Mercurial ist bekanntermaßen ein wenig in die Jahre gekommen. Auch die Art und Weise, Code Reviews durchzuführen, aktuell noch via Mailing-Listen, ist nicht wirklich modern. Git bietet hier adäquatere Alternativen. Ob diese am Ende allerdings auch zum Einsatz kommen, das wird nicht via JEP 357 beschlossen. Dieses JEP dient ausschließlich dem rein technischen Umzug zu Git, Änderungen am Entwicklungsprozess oder dem Bug-System (JBS) wird es vorerst nicht geben.

Projekt Skara & JEP 357: Java Repositorys bald auf Git

JEP 369 – Java goes to GitHub?

Nachdem Git offiziell als Ziel für den Duke und das JDK vorgeschlagen wurde, kam automatisch die Frage nach der passenden Hosting-Plattform auf. Die Autoren von JEP 357 schreiben hierzu: „We will not address the question of whether OpenJDK Git repositories will be self-hosted or hosted by an external provider. That issue will be the topic of a future JEP.“ Dieses JEP wurde mit JEP 369 – Migrate to GitHub jetzt offiziell nachgereicht. Auch hier war es, wie bereits bei der Wahl zu Git als VCS, eigentlich klar, dass die Migration zu GitHub am Ende tatsächlich als Vorschlag in JEP-Form gepresst werden würde.

Mit JEP 369 wird zunächst erst einmal vorgeschlagen, sämtliche Git Repositorys des OpenJDKs unter https://github.com/openjdk/ zur Verfügung zu stellen. Vor jedem Push soll dabei ein Check (via jcheck) stattfinden und existierende OpenJDK-Services sollen integriert werden. Erik Duveblad und Joe Darcy, die bereits für JEP 357 verantwortlich waren, wollen mit JEP 369 auch die verschiedenen Möglichkeiten, mit GitHub zu arbeiten, fördern und verfügbar machen.

Am Issue Tracker, Wiki oder anderen existierenden Infrastrukturen soll keine Änderung vorgenommen werden. Wohl aber sollen die Workflows für die Entwicklung, die derzeit via E-Mail und auf webrev basierend durchgeführt werden, mit den von GitHub zur Verfügung gestellten Mitteln abgebildet werden können. Es könnte also sein, dass die Mailing-Listen, die in JEP 357 noch unantastbar waren, nun zumindest auf User-Seite modernisiert werden. Im JEP wird vorgeschlagen, die Diskussionen in Pull Requests auf die OpenJDK-Mailing-Listen zu replizieren, was zur Vermeidung von Risiken ebenfalls wichtig wird.

Risiken und Nebenwirkungen

Natürlich möchte man gewisse Risiken explizit nicht eingehen. Ein Datenverlust in irgendeiner Form könnte fatale Folgen haben, daher wird auch im aktuellsten JEP betont, dass sämtliche existierenden Metadaten gespeichert und archiviert werden müssen. Einhergehend damit soll sichergestellt werden, dass der Umzug auf eine andere Hosting-Plattform zu jeder Zeit möglich ist. Auf Reddit gab es bereits Diskussionen darüber, dass ein „Vendor Lock-in“ oder eine Abhängigkeit drohen könnte. Ein weiteres Risiko ist natürlich, dass GitHub (theoretisch) jederzeit die Pforten schließen und seine Hosting-Tätigkeit einstellen könnte.

Die Frage, warum man überhaupt einen externen Hoster setzen sollte ist klar: Die Performance ist massiv, was sich für die Community in deutlich beschleunigten Klon- und Pull-Prozessen widerspiegeln wird. Die durch das Hosting auf etwa GitHub verfügbaren Web-APIs macht die Interaktion zwischen Anwendungen und Entwicklern auf der Plattform möglich. Zu guter Letzt ist natürlich die potentielle Vergrößerung der Community ein guter Beweggrund. Schon andere Projekte haben erfolgreich ihre Entwicklerzahlen vervielfacht, nachdem sie die Schwelle zur Mitarbeit durch das Hosting auf GitHub oder einer ähnlichen Plattform heruntergeschraubt haben.

Wie bereits erwähnt sind die Risiken bekannt und Vorkehrungen dagegen werden in JEP 369 bereits vorgeschlagen: So sollen die Diskussionen in Pull Request auf der OpenJDK-Mailing-Liste dupliziert und in verschiedenen Formaten (mbox und JSON) archiviert werden. Auch Push Notifications würden laut Vorschlag dann direkt an die entsprechende Mailing-Listen gesendet werden, was eine Abhängigkeit von GitHubs RSS Feeds ausschließt. Genauere Informationen, wie Abhängigkeiten und Risiken vermieden werden sollen, gibt es im JEP selbst.

Java 14: Z Garbace Collector auch für Windows und Adieu, Kombination aus ParallelScavenge & SerialOld

Aluhut glüht: Hat Microsoft seine Finger im Spiel?

Der Kauf von GitHub durch Microsoft war eine der Top-Storys im vergangenen Jahr. Ganze 7.5 Milliarden US-Dollar hatte sich Redmond die Entwicklerplattform kosten lassen. Auch wenn die Community damals seine Zweifel hatte, hat Microsoft das Octoversum nicht durchkommerzialisiert, somit hatte der Besitzerwechsel wenn überhaupt nur minimalinvasive Veränderungen mit sich gebracht. Microsoft hat seit der Ablöse von Steve Ballmer durch Satya Nadella im Jahr 2014 einen regelrechten Imagewandel durchlebt und ist heute dem Open-Source-Gedanken immer zugänglicher.

Und auch Java scheint dem Softwareriesen in all der Zeit immer mehr ans Herz gewachsen zu sein: In Kooperation mit Azul werden Java-Versionen mit Long-Term-Support und Mit-Term-Support angeboten und die Übernahme von jClarity, einem wichtigen Förderer des AdoptOpenJDK-Projekts, zeugt von der Liebe zum Duke. Microsoft bietet überdies auch Java-Laufzeiten auf in der hauseigenen Azure-Cloud an.

Im Oktober hatte Microsoft das Oracle Contributor Agreement unterschrieben, wie Bruno Borges, Product Manager für Java in der Microsoft Developer Division, auf der OpenJDK-Mailing-Liste bekannt gab. Die Frage ist nun, ob damals schon hinter verschlossenen Türen bekannt war, dass das OpenJDK offiziell die Migration auf Microsofts GitHub anstreben würde.

Weitere Informationen zu JEP 369 und dem potentiellen Hosting auf GitHub gibt es natürlich im entsprechenden Proposal. Wer gerne mehr über Microsofts Java-Engagement erfahren will, wird auf JAXenter fündig.

Verwandte Themen:

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: