Java 9-Funktionen

Oracle hat bekannt gegeben, dass die Veröffentlichung der ersten Erweiterungspläne für Java 9 (bekannt als JEPs) Anfang 2016 bestätigt wurde.

Drei neue APIs wurden angekündigt:

Nach dem Update kann die Prozess-API mit nicht-JAVA-bezogenen Prozessen im Betriebssystem interagieren. Die derzeit verwendeten APIs weisen viele Einschränkungen auf, was Entwickler zwingt häufig auf nativen Code zurückgreifen. Das Hauptrisiko dieser API ist die Heterogenität der Betriebssysteme, insbesondere von Windows. Das Design der API muss an die Bereitstellung kleiner Geräte auf verschiedenen Betriebssystemen angepasst werden. Dabei sollte auch die Umgebung berücksichtigt werden, in der mehrere Java Virtual Machines im selben Betriebssystemprozess ausgeführt werden. Diese Überlegungen werden zu einer abstrakteren API führen, was den Designaufwand erhöhen wird.

Neuer HTTP-Client, der Unterstützung für HTTP/2 einführt.

Probleme und Implementierung bestehender APIs:

APIs, die auf URLConnection basieren, wurden unter Berücksichtigung mehrerer Protokolle entwickelt, von denen viele aufgegeben wurden (FTP, Gopher usw.)

Früheres HTTP 1.1 war zu abstrakt

Schwierig zu verwenden (viele Verhaltensweisen wurden nicht dokumentiert)

Funktionierte nur im Blockierungsmodus (ein Thread pro Anfrage/Antwort)

Sehr schwierig zur Aufrechterhaltung

Die HTTP 2.0-Unterstützung basiert auf TLS ALPN (Application Layer Negotiation Extension), das derzeit im JDK nicht unterstützt wird. Die HTTP 2.0-Spezifikation selbst liegt noch in Form eines Internetentwurfs vor, wird aber erwartet soll 2014 verfügbar sein. Werden Sie ein offizieller Entwurf.

Neue leichtgewichtige JSON-API: Sie stellt eine leichtgewichtige API für die Verarbeitung und Generierung von JSON-Dokumenten und Datenströmen bereit. Letztere basiert auf standardisierter JSON-Unterstützung und ist Teil von JSR 353.

Es wurden außerdem drei JVM- und leistungsbezogene Funktionen angekündigt:

Verbesserte Konfliktsperren, die die Leistung verbessern sollen, wenn Threads um den Zugriff auf Objekte konkurrieren. Eine Verbesserung der Konkurrenzsperre wäre für reale Anwendungen von großem Nutzen, insbesondere im Vergleich zu Industrie-Benchmarks wie Volano und DaCapo.

In diesem Projekt werden Leistungsverbesserungen in den folgenden Bereichen im Zusammenhang mit konkurrierenden Java-Monitoren untersucht:

Feldneuordnung und Cache-Zeilenausrichtung

Accelerate PlatformEvent::unpark()

Schneller Java-Monitor-Eintrittsvorgang

Schneller Java-Monitor-Austrittsvorgang

Schnelle Java-Monitor-Benachrichtigung/ Adaptive Spin-Verbesserungen für notifyAll-Vorgang

und SpinPause auf SPARC

Teilen Sie den Code-Cache des JIT-Compilers auf (für eine bessere JIT-Leistung bei großen Anwendungen). Durch die Aufteilung des Codecaches in unabhängige Segmente, die jeweils eine bestimmte Form kompilierten Codes enthalten, soll die Leistung verbessert und zukünftige Erweiterungen unterstützt werden.

Die Organisation und Wartung des kompilierten Codes hat große Auswirkungen auf die Leistung. Wenn der Code-Cache in die falsche Richtung geht, sind mehrere Fälle von Leistungseinbußen bekannt. Nach der Einführung der mehrstufigen Kompilierung wird der Status des Code-Caching äußerst wichtig, da sich die Menge des kompilierten Codes im Vergleich zur Nichtverwendung der mehrstufigen Kompilierung um das Zwei- bis Vierfache erhöht. Durch die mehrstufige Kompilierung wird auch eine neue Art von kompiliertem Code eingeführt: instrumentierter kompilierter Code (isolierter Code). Alien-Code hat andere Eigenschaften als nicht profilierter Code. Ein wichtiger Unterschied besteht darin, dass profilierter Code im Gegensatz zu nicht profiliertem Code, der immer im Code-Cache verbleibt, einen vordefinierten eingeschränkten Lebenszyklus hat.

Der vorhandene Code-Cache ist für einen einzelnen Code optimiert, d. h. es gibt nur eine Form von kompiliertem Code. Der Code-Cache ist als separate Heap-Datenstruktur organisiert, die sich am Kopf eines zusammenhängenden Speicherblocks befindet. Dadurch wird profilierter Code mit einer vordefinierten restriktiven Lebensdauer mit nicht profiliertem Code vermischt und verbleibt dauerhaft im Code-Cache, was zu unterschiedlichen Leistungs- und Designproblemen führt. Beispielsweise wird die Sweeper-Methode beim Scannen gezwungen, den gesamten Code-Cache zu scannen, auch wenn einige Entitäten darin nie aktualisiert werden oder Nicht-Methodencode vorhanden ist.

Eine tiefgreifende Entwicklung eines „intelligenten“ Java-Compilers namens sjavac, der unter anderem parallele und gemeinsame Kompilierung unterstützt.

Aufgrund verschiedener Stabilitäts- und Portabilitätsprobleme wird sjavac standardmäßig nicht in JDK-Build-Skripten verwendet. Das erste Ziel dieses JEP besteht darin, diese Probleme zu lösen, was die Bereitstellung der erforderlichen Tools erfordert, die auf der gesamten Hardware konsistent zuverlässige Ergebnisse liefern und Softwarekonfigurationen.

Das übergeordnete Ziel besteht darin, die Qualität von sjavac zu verbessern und es zu einem universellen Javac-Paket zu machen, das in der Lage ist, verschiedene große Java-Projekte zu kompilieren.

Folgeprojekte werden weiterhin untersuchen, wie Sjavac nach Möglichkeit in der JDK-Toolkette getrennt werden kann. sjavac kann ein eigenständiges unterstütztes Tool, ein nicht eigenständiges Tool, das in Javac integriert ist, oder etwas anderes werden.

Schließlich wurde in JEP 201 eine verlockende Funktion versprochen: modularer Quellcode. Dies ist eigentlich das, was wir einst als modulare Lösung „Project Jigsaw“ kannten (ursprünglich als Teil von Java 8 vorgesehen).

Das Jigsaw-Projekt zielt darauf ab, ein standardisiertes Modulsystem für die Java SE-Plattform zu entwerfen und zu implementieren, es auf die eigene Plattform anzuwenden und es dann in das JDK zu investieren. Seine ursprünglichen Ziele bestehen darin, Plattformimplementierungen leichter auf kleine Geräte skalierbar zu machen, die Sicherheit und Wartbarkeit zu verbessern, die Anwendungsleistung zu verbessern und Entwicklern bessere Tools für große Anwendungen zur Verfügung zu stellen.

Dieses JEP ist Teil der ersten Phase des Jigsaw-Projekts. Als Nächstes wird das JEP die JRE- und JDK-Images modularisieren und anschließend ein Modulsystem einführen.

Die Motivation für die Neuorganisation des Quellcodes in der frühen Phase ist:

Geben Sie JDK-Entwicklern die Möglichkeit, sich mit der modularen Struktur des Systems vertraut zu machen.

Verbessern Sie die Struktur weiter, indem Sie Modulgrenzen in Builds durchsetzen, noch bevor das Modulsystem eingeführt wird.

Tiefgehende Entwicklung von Jigsaw-Projekten statt immer „langsames“ Konvertieren von vorhandenem nicht-modularem Code in modularen Code.