Suche
Kehraus im Hause Oracle

Java 10: Diese APIs sollen entfernt werden

Hartmut Schlosser, Marcel Richters

© Shutterstock / Pro100 Dzu

Java schleppt noch immer zeilenweise veralteten Code mit sich herum. Bisher war dieser bereits am @Deprecated-Tag zu erkennen. Da diese Markierung aber nicht unbedingt die bevorstehende Löschung bedeutet, haben sich die Entwickler bei Oracle etwas ausgedacht.

Java 10 steht vor der Tür, und da bleiben ein paar Änderungen nicht aus. Auch einigen APIs wird es wohl an den Kragen gehen. Doch welche sind es genau?

Bisher markierte die Annotation @deprecated veraltete Elemente des JDK. @deprecated hatte allerdings eher den Status einer Warnung und bedeutete nicht zwangsläufig, dass die entsprechenden Elemente auch tatsächlich in der nächsten JDK-Version verschwunden waren. So sind in JDK 9 etwa Elemente wie java.security.acl.Acl enthalten, die seit Java 1.2 als veraltet gelten.

Um klar zu machen, welche Elemente in zukünftigen Java-Versionen tatsächlich entfernt werden sollen, kann @Deprecated seit Java 9 um forRemoval() erweitert werden. Steht forRemoval() auf „true“, sind die entsprechenden Elemente markiert, um „in einem kommenden Release“ entfernt zu werden. Damit ist man zwar einen Schritt weiter. Welche Elemente aber konkret im nächsten Release nicht mehr dabei sein werden, bleibt unklar.

Momentan sieht es so aus, als seien neun Elemente für die Entfernung aus Java 10 vorgesehen. Der aktuelle Entwurf für die Java SE 10 (JSR 383) Proposed Final Draft Specification listet die folgenden auf:

In einem früheren Entwurf war auch die vollständige Entfernung einiger SecurityManager-Methoden und Felder geplant, derzeit scheint es aber so, als würden sie in Java 10 noch Teil des Codes bleiben. Da aber auch diese Abschnitte seit Version 1.2 veraltet sind, ist davon auszugehen, dass sie – wie wohl auch viele der anderen markierten Teilstücke – in naher Zukunft gestrichen werden. Ein großer Verlust werden die zu tilgenden Elemente trotz ihrer Sicherheitsrelevanz aber nicht sein, da sie bereits durch andere Konstruktionen ersetzt worden sind.

In Java 9 für eine Entfernung vorgeschlagen, aber dennoch in Java 10 enthalten, sind voraussichtlich die folgenden Elemente:

Module

Klassen

Methoden

In Java 10 soll es darüber hinaus eine Reihe von neuen Elementen geben, die forRemoval=true erhalten werden:

Packages

Interfaces

Klassen 

Exceptions

Felder 

Methoden  

Java 10 – das ist drin

Man sieht, die Aufräumarbeiten im JDK gehen weiter. Doch natürlich wird Java 10 nicht nur alte Zöpfe abschneiden. Auf Feature-Seite wurden insgesamt 12 JEPs (Java Enhancement Proposals) umgesetzt:

JEP 286: Local-Variable Type Inference

JEP 286 wird es Entwicklern ermöglichen, ihren Java-Code kompakter zu formulieren, ohne dabei die Typensicherheit aufzugeben. Entwicklern können dann die oft unnötige Manifest-Deklaration lokaler Variablentypen umgehen. Die Abkürzung beschränkt sich aber auf lokale Variablen mit Initializers, Indizes in erweiterten for-Schleifen und Lokale, die in einer traditionellen for-Schleife deklariert sind. Sie ist nicht verfügbar für Method Formals, Constructor Formals, Methodenrückgabetypen, Felder, Catch Formals oder jede andere Art von Variablendeklaration.

JEP 296: Consolidate the JDK Forest into a Single Repository

In diesem JEP geht es darum, die zahlreichen Repositories des JDK in ein einziges Repository zu überführen, um die Entwicklung zu vereinfachen und zu rationalisieren. Bisher besteht das JDK 9 aus acht Repos: root, corba, hotspot, jaxp, jaxws, jdk, langtools und nashorn. Die FX Sourcen sind nicht Teil des Proposals.

JEP 304: Garbage-Collector Interface

Der JEP 304 wird die Isolierung der verschiedenen Garbage Collectors (GC) verbessern, indem es ein sauberes Interface für die Garbage Collectors integriert. Das soll zu einer besseren Modularität für die HotSpot VM und internen GC-Code führen. Außerdem soll es einfacher werden, einen neuen GC zu HotSpot hinzuzufügen, ohne den bestehenden Code zu stören. GCs aus einem JDK Build auszuschließen soll damit ebenfalls einfacher werden.

JEP 307: Parallel Full GC for G1

Ebenfalls um den Garbage Collector geht es im JEP 307. Das Proposal will die Latenz des in Java 9 zum Standard erklärten Garbage Collectors G1 verbessern, indem der ganze GC parallelisiert wird. Dies soll sich vor allem auf Use Cases auswirken, bei denen die Latenz besonders leidet.

JEP 310: Application Class-Data Sharing

Um die Startzeit und den Footprint zu verbessern, wird das existierende Class-Data Sharing (CDS) Feature weiter ausgebaut. Das Feature erlaubt es Entwicklern, Applikations-Klassen in geteilten Archiven zu nutzen.

JEP 312: Thread-Local Handshakes

Das Proposal wird es ermöglichen, einen Callback auf Threads auszurufen, ohne dass ein globaler VM Safepoint durchgeführt wird. Damit lassen sich individuelle Threads einfach stoppen und nicht nur alle Threads auf einmal.

JEP 313: Remove the Native-Header Generation Tool (javah)

Mit diesem JEP wird das Tool javah aus dem JDK verschwinden. Denn das Tool wird nicht mehr gebraucht, da es mittlerweile bessere Funktionen in javac gibt, die mit JDK 8 eingeführt wurden. jacac bietet die Möglichkeit, native Header-Dateien zum Zeitpunkt der Kompilierung des Java-Quellcodes zu schreiben, wodurch ein separates Tool überflüssig wird.

JEP 314: Additional Unicode Language-Tag Extensions

java.util.Locale und die zugehörigen APIs werden ausgebaut, um zusätzlichen Unicode Extensions der BCP 74 Sprach-Tags zu implementieren. Die Sprach-Tags kamen ursprünglich in Java 7 dazu, beschränken sich aber auf Kalender (ca) und Nummern (nu). Neu hinzu kommen first day of week (fw), region override (rg) und time zone (tz).

JEP 316: Heap Allocation on Alternative Memory Devices

In JEP 316 geht es darum, der HotSpot VM zu ermöglichen, den Java Object Heap auf alternativen Speichern zu allokieren, die der Anwender spezifizieren kann. Ein Beispiel für einen solchen Speicher sind NV-DIMMs. Entwickler können dann wichtige Prozesse auf DRAM-Speicher laufen lassen und große, aber weniger wichtige auf dem günstigen NV-DIMM-Speicher, ohne ihren Applikationscode anpassen zu müssen.

JEP 317: Experimental Java-Based JIT Compiler

Als experimenteller Compiler kommt der Java-basierte JIT Compiler, Codename Graal, für Linux/x64. Graal ist die Grundlage für den ebenfalls experimentellen Ahead-of-Time (AOT) Compiler, der in JDK 9 eingeführt wurde. Der Compiler ist Teil des Projekts Metropolis.

JEP 319: Root Certificates

Das Ziel vom JEP 319 ist es, die Root-Zertifikate von Oracles Root-Certification-Authority-Programm für Java SE Open Source zur Verfügung zu stellen. Das soll OpenJDK Builds für Entwickler attraktiver machen. Außerdem soll es die Unterschiede zwischen den verschiedenen Builds verringern.

JEP 322: Time-Based Release Versioning

Und zu guter Letzt gehört auch das neue Versionierungsschema für die sechsmonatigen Java Releases zu Java 10. Wir haben uns diesen JEP hier genauer angesehen.

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Marcel Richters
Marcel Richters
Marcel hat Soziologie an der Goethe-Universität in Frankfurt am Main studiert und danach als E-Commerce-Manager gearbeitet. Seit Februar 2018 unterstützt er das Team von JAXenter als Redakteur. Daneben arbeitet er als freier Journalist in der Mainmetropole.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.