Java 16 migriert zu GitHub und unterstützt Alpine Linux

Inhaltsverzeichnis

Mit Java 16 ist das letzte Release vor der für den Herbst 2021 angekündigten nächsten Version mit Long-term Support erschienen, wie Mark Reinhold über die offizielle Mailing-Liste nun angekündigt hat. Die letzte Referenzimplementierung davor war Java 15, das am 15. September 2020 herausgekommen war. Das JDK 16 (Java Development Kit) wartet mit etlichen neuen Features auf: Insgesamt waren 17 Proposals mit Änderungsvorschlägen eingegangen.

Die neue Version knöpft sich die Klassen weiter vor und umfasst eine zweite Preview zu den versiegelten Klassen, sie bietet Portierungen für Alpine Linux und Windows unter ARM64. C++14-Features sind neu mit an Bord, und nebenläufiges Thread-Stack Processing ist implementiert. Richtungweisend ist wohl der Wechsel der Versionsverwaltung: Java 16 ist von Mercurial zu Git migriert und dabei auch zur Plattform GitHub als neuem Host übersiedelt (JEP 357 und 369).

Single-Repository-Projekte übersiedeln zu Git

Der Umzug umfasst alle OpenJDK-Projekte, die sich in einem einzigen Repository befinden. Das betrifft auch alle Update-Releases ab Java 11. Der Verlauf der Versionskontrolle und die Tags sollen dabei erhalten bleiben. Auch die dazugehörigen Tools jcheck, webrev und defpath ziehen mit um zu Git. Das Team hinter JEP 357 (Java Enhancement Proposal) soll auch ein Werkzeug entwickelt haben, mit dem sich Mercurial-Hashes in Git-Hashes übersetzen lassen (und umgekehrt).

OpenJDK-Projekte, die auf mehrere Repositories aufgeteilt sind (wie es bei den Updates zu JDK 8 noch der Fall ist), bleiben der Ankündigung zufolge vorerst bei Mercurial. Sobald diese Projekte in ein einziges Repository konsolidiert sind, steht auch ihnen der Umzug bevor (JEP 357). Gründe für den Wechsel sind laut JEP-Initiatoren die verfügbaren Werkzeugsätze, die Hosting-Optionen und der Umfang der zu hostenden Metadaten des Versionskontrollsystems.

Müllabfuhr: Thread-Stack Processing ist jetzt lazy

Das Thread-Stack Processing des Z Garbage Collector (ZGC) haben die Entwickler von den Safepoints in eine nebenläufige Phase verschoben. Die Verarbeitung des Stacks gilt damit als lazy (bedarfsorientiert), nebenläufig und inkrementell. Auch das weitere Thread-weise Root-Processing ist aus den ZGC-Safepoints entfernt, denn ein neuer Mechanismus erlaubt es HotSpot-Untersystemen, die Prozessverarbeitung nach Bedarf durchzuführen (JEP 376).

Hands-on Java: Workshops

Heise veranstaltet im März 2021 drei Java-Workshops:

• 22. März: Coole neue Java-Features - besserer Code mit Java 9 bis 16
• Best-of-Java, Hands-on: Ein Workshop zur Vorbereitung auf das bevorstehende Release von Java 16 und das kommende Long-term-Release Java 17. Trainer: Michael Inden
• 23. März: JUnit 5: Testing reloaded. Wie das Schreiben von Unit-Tests wieder Spaß macht
• Fundierter Einstieg in das wohl populärste Unit-Testing-Framework für Java. Passende und wartbare Tests mit JUnit 5 erstellen, parametrisierte Tests und Praxistauglichkeit. Trainer: Michael Inden
• 24. März: GraphQL für Java-Anwendungen
• Effizient Daten austauschen mit der Abfragesprache GraphQL: ein Workshop zu Grundlagen und Konzepten. Trainer: Nils Hartmann

Neue Vektor-API

Mit einer neuen Vektor-API sollen sich Vektorberechnungen ausdrücken lassen, die auf unterstützten CPU-Architekturen zur Laufzeit in geeignete Vektor-Hardware-Anweisungen kompilieren. Die Performance soll sich dadurch der von gleichwertigen skalaren Berechnungen annähern. Die API gilt als agnostisch hinsichtlich der zugrundeliegenden Architektur und soll Runtime-Implementierungen auf mehreren CPU-Architekturen ermöglichen. Die Herausforderung lag laut Projekt-Entwicklern offenbar darin, die API zugleich portierbar zu halten (einige plattformspezifische Ausdrücke lassen sich wohl nicht unmittelbar in portierbaren Code umsetzen). In Fällen, wo sich die Vektorberechnung nicht vollständig zur Laufzeit als Sequenz von Hardware-Anweisungen ausdrücken lässt, soll die neue Vektor-API behutsam abstufen und dennoch funktionieren.

Portierungen für Alpine Linux und für Windows mit ARM64

Zwei Portierungen sind neu: JDK 16 unterstützt Alpine Linux und weitere Linux-Distributionen wie OpenWrt, die musl als primäre C-Bibliothek verwenden. Eine Reihe von Linux-Distributionen wie Arch Linux stellen optional ein musl-Paket bereit. Alpine Linux ist in der Cloud, bei Microservices und in Containerumgebungen verbreitet, da es nur wenig Speicherplatz benötigt (das Basis-Docker-Image für Alpine Linux beansprucht lediglich 6 MByte).

Tomcat, Jetty, Spring und andere Frameworks sollen in dieser Umgebung nativ laufen können, da Java bereits gebrauchsfertig vorkonfiguriert ist (out of the box). Auch für eingebettete Systeme ist der Speicherbedarf von Belang, da hier hardwarebedingte Obergrenzen bestehen. JDK 16 ist auch zu Windows mit der ARM64-Architektur portiert – laut JDK-Entwicklern sei das wegen der großen Nachfrage nach den neuen ARM-Servern und Consumer-Hardware mit ARM64 notwendig geworden. Mit dem Release soll die Integration in das JDK-Repository abgeschlossen sein.

Behutsame Modernisierung bei den C++-Features im JDK

Die Aktivierung von C++14-Features im C++-Quellcode des JDK umfasst der Ankündigung zufolge auch Handreichungen, welche der Features im HotSpot-Code der Virtual Machine (VM) sinnvoll einsetzbar sind. Bis einschließlich JDK 15 waren Sprachfeatures von C++ im Development Kit im Wesentlichen auf den veralteten Standard C++98/03 beschränkt. Behutsame Modernisierung fand mit der Long-term-Version JDK 11 statt, die immerhin schon den Einsatz aktuellerer C++-Standards erlaubte. Die Neuerung in JDK 16 bleibt weiterhin auf den C++-Code in HotSpot beschränkt und soll unter anderem zeitgemäßere Compilerversionen unterstützen.

Klassen und Schnittstellen

Weitere Änderungen betreffen die Java-Klassen: Primitive Wrapper-Klassen gelten neuerdings als wertbasiert, ihre Konstruktoren sind als veraltet (deprecated) markiert und zur Entfernung vorgesehen, was wohl neue Deprecation-Warnungen auslösen wird. Das Design und die Implementierung primitiver Klassen in Java gilt nun als hinlänglich ausgereift, sodass einige Klassen der Java-Plattform wohl in künftigen Releases zu den Primitive-Klassen migrieren könnten. Als Kandidat für solch eine Migration gelten die wertbasierten Klassen in den API-Spezifikationen. Das Valhalla-Projekt betreibt die Renovierungsmaßnahmen mit dem Ziel, das Java-Programmierungsmodell durch die Erweiterung primitiver Klassen zu überarbeiten.

Ausblick auf Java 17

• Im Herbst kommt Java 17 – ein Ausblick: Eine einheitliche API und neue Rendering-Pipeline für macOS sollen an Bord sein. Das Release erhält Long-term Support.

Versiegelte Klassen und Schnittstellen hatten zuletzt bereits bestimmt, welche anderen Klassen und Schnittstellen sie erweitern oder implementieren dürfen. Das soll offenbar den Urhebern von Code eine gewisse Kontrolle darüber verschaffen, in welcher Weise ihre APIs in Folge zum Einsatz kommen. Nach der ersten Preview in JDK 15 ist das Feature in JDK 16 als zweite Preview enthalten.

Weitere Änderungen und weiterführende Hinweise

Eine Reihe weiterer Änderungen haben in das neue JDK Einzug gehalten, zum Beispiel die starke Einkapselung von JDK-Internals als Grundeinstellung (außer bei kritischen internen APIs), die Foreign Linker API für statisch typisierten Zugang zu Java-Code und elastische Metaspace-Fähigkeiten zur Ausgabe ungenutzter Metadaten von HotSpot-VM-Klassen.

Eine vollständigere Auflistung der Proposals und Neuerungen lässt sich der JDK-16-Instanz bei OpenJDP entnehmen. Builds für Linux, Windows und Mac stehen auf der jdk-Javanet-Website bereit. Zurzeit ist das aktuellste JDK mit Long-term Support noch JDK 11, das im September 2018 auf den Markt kam. Für den Herbst ist JDK 17 mit Langzeit-Support angekündigt: Es soll alle Features und Neuerungen von JDK 11 bis 16 umfassen.

Siehe dazu auch:

• Java Standard Edition: Download sicher und schnell von heise.de

(sih)