Java 21 Release

[KonradN]

Nun ist das Java 21 Release draußen.

Die wichtigste Neuerung wird wohl virtuelle Threads (Project Loom) sein, das nun die Preview-Phase verlassen hat. Aber es gilt noch anzumerken: Scoped Values und Structured Concurrency sind Preview)

Die Performance Verbesserungen durch den Generational ZGC sind bestimmt auch für den einen oder anderen interessant.

Ansonsten gibt es viele Dinge im Preview, die sich sehr interessant anhören aber da es noch in preview ist, weise ich da nicht weiter darauf hin. Aber die Erweiterungen der Sprache sind aus meiner Sicht eine gute Weiterführung der bisherigen Entwicklung.

Oracle Releases Java 21 and Extends Support Roadmap
JEP 444: Virtual Threads (openjdk.org)
JEP 446: Scoped Values (Preview) (openjdk.org)
JEP 453: Structured Concurrency (Preview) (openjdk.org)
JEP 439: Generational ZGC (openjdk.org)

 

[KonradN]

Ach ja - vergessen zu erwähnen: Java 21 ist wieder ein LTS Release.

 

[LimDul]

Mal sehen wann wir bei uns da ankommen. Sind immerhin schon bei 11

 

[KonradN]

Und wie zu erwarten war: Auch das Java Magazin von Oracle beschäftigt sich gleich mit zwei Artikeln mit Java 21, speziell den neuen virtuellen Threads:
Java 21 is here: Virtual threads, string templates, and more (oracle.com)
Virtual threads: Are futures a thing of the past? (oracle.com)

 

[Barista]

Und wie zu erwarten war: Auch das Java Magazin von Oracle beschäftigt sich gleich mit zwei Artikeln mit Java 21, speziell den neuen virtuellen Threads

Ich habe auch ein bisschen dazu im Netz gelesen.

Ich hätte erwartet, dass etwas so Einfaches wie ein Generator als Beispiel erwähnt wird, aber nicht gefunden.

Irgendwo habe ich dann ein Beispiel gefunden (Link habe ich nicht mehr), auf dem das Ganze mit einem speziellen API mit benannten Code-Punkten (Strings) gelöst wurde .

Ich hätte erwartet, dass man eine Queue verwendet, es gibt im JDK eine Queue mit der Größe 1, also sozusagen eine Rendezvous-Queue.

Ein Producer-Thread schreibt in die Rendezvous-Queue und ein Consumer-Thread liest aus der Rendezvous-Queue.

Dann könnte man sich den Aufwand des Status-Haltens in einem Iterator sparen.

Im Sinne des Nichtblockierens würde dann unter dem API(der Technologie) das Queue-wait den virtuellen Producer-Thread stilllegen und der Consumer-Thread wäre der Träger-Thread.

Auch habe ich keine Beispiele gefunden, bei denen ein Protokoll zwischen Client und Server abgearbeitet wird, etwa: "Gib Benutzername, Gib Passwort, Gib Actions-Code, Arbeite Aktion(zum Beispiel stückweisen Download) ab".

Ich habe solche Sachen mit einem Command-Pattern im Client und mit einer Command-ArrayList mit Vermerken aktueller Status (Instruction Pointer) im Server gelöst.

Der durch Projektleiter erzwungene Ausflug in reaktive Programmierung ist leider gescheitert, eventuell bin ich dafür zu einfach gestrickt (Unfolding ???).

Wie es aussieht, bleibe ich wahrscheinlich bei meiner bisherigen Lösung, Loom scheint mir dabei nicht zu helfen.

 

[Barista]

Eventuell auch interessant in diesem Kontext:

Github.com/HeinerKuecker/Coroutine-in-pure-Java

Das war ein Schnellschuss, sozusagen im Tunnel geschrieben, als Speicher habe ich eine HashMap verwendet.

Ich habe damals schon überlegt, statt der HashMap die lokalen Variablen der Koroutine als Member im einem Koroutinen-Objekt festzulegen, die dann über die Festlegung des Koroutinen-Objekts über Generics dem einzelnen Statements bekannt gemacht worden wären.

Ich hab es dann nicht mehr verfolgt.