Java 10 wird herauskommen. Es gab kein Java 9! Ich bin mir jedoch nicht sicher, welche Art von Funktion es hat, deshalb werde ich es zusammenfassen. Es ist wie eine kurze Einführung in die hier aufgestellten JEPs. http://openjdk.java.net/projects/jdk/10/
Andere Änderungen als JEP, wie das Hinzufügen von API, werden hier zusammengefasst. Zusammenfassung anderer Änderungen als JEP in Java 10 - Qiita
Alle Änderungen sind hier zusammengefasst. 109 New Features In JDK 10 - Azul Systems, Inc.
Klicken Sie hier, um OpenJDK herunterzuladen JDK 10 GA Release
Klicken Sie hier, um das Oracle JDK herunterzuladen Java SE Development Kit 10- - Downloads
286: Local-Variable Type Inference http://openjdk.java.net/jeps/286
Die wahrscheinlich größte und einzige Änderung beim Schreiben von Code ist die Inferenz lokaler Variablentypen.
var str = "123";
var list = List.of("123");
Sie können so schreiben. Wenn Sie es beim Schreiben von Code verwenden, kennen Sie normalerweise den Typ der Variablen oft nicht, und es ist leicht abzulehnen, den Typ, den Sie bisher kannten, nicht zu kennen. Daher gibt es meines Erachtens nur wenige Situationen, die unerwartet verwendet werden können. Ist es möglich, es vorerst zu verwenden, wenn der Typ bis zu einem gewissen Grad wie folgt explizit ist?
var strs = new ArrayList<String>(); //Neu
var props = (Map<String, List<String>>)input.getAsObject("props"); //Besetzung
var map = Map.of("apple", "Apfel",
"grape", "Traube"); //Fabrik oder Baumeister
Zusammenfassend ist, wenn der Typ auf der rechten Seite geschrieben ist, er auf der linken Seite nicht erforderlich und var kann verwendet werden, andernfalls wird var nicht verwendet.
In JShell ist dies jedoch unbedingt erforderlich.
Das Lambda-Argument ist, wo var zu funktionieren scheint und nicht.
Stream.of("abc").forEach(s -> System.out.println(s));
Ist
Stream.of("abc").forEach((String s) -> System.out.println(s));
Dies ist eine Typinferenz von
Stream.of("abc").forEach((var s) -> System.out.println(s));
Kann nicht geschrieben werden. Nun, es ist eine Inferenz vom Typ einer lokalen Variablen, und das Lambda-Argument ist keine lokale Variable, daher kann es nicht verwendet werden. Nun, es sieht so aus, als ob es verwendet werden kann. Ab Java 11 können Sie also "var" mit Lambda-Argumenten verwenden.
Mit der Einführung von var haben sich auch die Sprachspezifikationen von Zeit zu Zeit geändert. Als große Sache wird var als Reservierungstyp eingeführt, nicht als Reservierungswort. Sie können also var für Variablennamen, Methodennamen und Paketnamen verwenden, var für Klassennamen jedoch nicht mehr. In der Sprachspezifikation wird anstelle von Bezeichner für Typen der Typbezeichner eingeführt, und der Teil, in den der Typ geschrieben werden kann, wurde von Bezeichner zu Typbezeichner geändert.
Sie können dies auch tun.
var anon = new Object() {
private int a() {
return 3;
}
};
System.out.println(anon.a());
Apropos
var s = List.of("a", 1);
Das Kompilieren von Code mit der Option -g führt zum Absturz von Javac in Build 46.
Diese sind in Ordnung.
var t = List.of("a");
var u = List.of("a", 1, Optional.empty());
var v = List.of("a", 1, List.of());
Bitterfox hat uns bereits einen Patch geschickt.
296: Consolidate the JDK Forest into a Single Repository http://openjdk.java.net/jeps/296
Von nun an spielt es beim Schreiben von Code keine Rolle mehr, also lasst es uns schnell streamen. JEP 296 integriert das Repository in das OpenJDK. Es folgt dem Trend der jüngsten Single-Repositories. Bisher war das Abrufen der OpenJDK-Quelle wie das Sammeln aus verschiedenen Repositorys mit einem Skript. Jetzt können Sie die Quelle mit einem einzigen Mercurial-Befehl abrufen. Ich denke, die Entwicklung wird einfacher.
Wie Sie im JDK9-Repository sehen können, enthält jedes 7 Repositorys. http://hg.openjdk.java.net/jdk9
Das alte Repository bleibt in JDK10, ist jedoch in den Master integriert. http://hg.openjdk.java.net/jdk10
Und da die Repositorys integriert wurden, scheint es, als würde jedes Versions-Repository unter dem JDK-Projekt erstellt, das früher für jede Version ein separates Projekt war. http://hg.openjdk.java.net/jdk
304: Garbage-Collector Interface http://openjdk.java.net/jeps/304
Wir haben eine GC-Schnittstelle eingeführt, um den GC unabhängig von der JVM zu machen. Dies erhöht die Modularität des GC und erleichtert das Hinzufügen und Entfernen von GCs. In Java 11 gibt es einen netten GC namens Epsillon GC (GC, der überhaupt keinen Speicher freigibt), ZGC wird Open Source, Shenandoah usw. Ich denke, dass es in Zukunft einfacher sein wird, GC zu verschieben.
307: Parallel Full GC for G1 http://openjdk.java.net/jeps/307
Die Worst-Case-Latenz in G1GC soll durch Parallelisierung von Full GC verbessert werden. G1GC ist der Standard von Java 9 geworden, aber es scheint, dass der parallele GC, der der Standard-GC bis Java 8 ist, parallel den vollständigen GC ausführte, sodass die Migration reibungsloser erfolgen kann.
310: Application Class-Data Sharing http://openjdk.java.net/jeps/310
Durch die Bereitstellung von in JDK 5 eingeführtem Class Data Sharing (CDS) für Anwendungsklassen können Klassenmetadaten zwischen Java-Prozessen gemeinsam genutzt und die Startzeit und die Speichernutzung verbessert werden.
312: Thread-Local Handshakes http://openjdk.java.net/jeps/312
Ermöglicht die Ausführung einzelner Thread-Rückrufe, ohne den Sicherheitspunkt der gesamten VM zu beeinträchtigen. Es scheint, dass dies die Erfassung von Stapelspuren und die GC verbessern wird.
313: Remove the Native-Header Generation Tool (javah) http://openjdk.java.net/jeps/313
Da Java 8 mit javac C-Header für JNI generieren kann, wird javah entfernt.
314: Additional Unicode Language-Tag Extensions http://openjdk.java.net/jeps/314
java.util.Locale Erweiterte Unterstützung für BCP47-Sprach-Tags in anderen APIs. Was in Java7 vom Kalender "ca" und der Nummer "nu" unterstützt wurde, wird erweitert, um die Währung "cu", den Wochenbeginn "fw", die Region "rg" und die Zeitzone "tz" zu unterstützen ..
316: Heap Allocation on Alternative Memory Devices http://openjdk.java.net/jeps/316
Ermöglicht das Platzieren von Java-Objekt-Heaps auf anderen benutzerdefinierten Speichergeräten, z. B. NV-DIMMs. Zukünftige Systeme werden eine komplexe Speicherarchitektur mit Speicher wie 3D XPoint haben, die zusätzlich zum DRAM Nicht-DRAM mit unterschiedlichen Eigenschaften verwenden wird. Als Anwendungsbeispiel wird angenommen, dass der Prozess mit hoher Priorität DRAM verwendet, der Prozess mit niedriger Priorität NV-DIMM verwendet oder NV-DIMM für Big Data oder In-Memory-DB verwendet wird.
317: Experimental Java-Based JIT Compiler http://openjdk.java.net/jeps/317
Aktivieren Sie als Test Graal, einen Java-basierten JIT-Compiler, auf Linux / x64-Plattformen. Obwohl Graal die Grundlage für die in JDK 9 eingeführte Vorkompilierung (AoT) ist, kann es auch als JIT-Compiler verwendet werden, um die nächste Stufe der Java-basierten JIT zu erkunden.
319: Root Certificates http://openjdk.java.net/jeps/319
OpenJDK verfügt standardmäßig nicht über ein Stammzertifikat, und sicherheitsrelevante Funktionen wie TLS funktionierten nicht. Bereiten Sie daher ein Stammzertifikat vor, um die Entwicklung mit OpenJDK zu vereinfachen und mit Oracle JDK einen Unterschied zu machen. Es scheint.
322: Time-Based Release Versioning http://openjdk.java.net/jeps/322
Die Versionsbeschreibung wird als Reaktion auf die zeitbasierte Veröffentlichung überarbeitet.
Es hat das folgende Format.
$FEATURE.$INTERIM.$UPDATE.$PATCH
Mit der halbjährlichen Veröffentlichung erhöht sich "$ FEATURE" um 1 und "$ UPDATE" auf 0. $ INTERIM ist immer 0. Ein $ UPDATE wird für Wartungsversionen einen Monat und vier Monate nach der Funktionsfreigabe hinzugefügt. $ PATCH wird normalerweise nicht verwendet.
Die nächste Veröffentlichung im März wird Oktober sein. Die Veröffentlichung im April wird 10.0.1 sein. Die Veröffentlichung im Juli wird 10.0.2 sein und die Veröffentlichung im September wird 11 sein.
Diese Versionsnummern können mit "feature ()", "interim ()", "patch ()" und "update ()" von "java.lang.Runtime.Version" abgerufen werden.
Recommended Posts