OpenJDK-Projekt Amber für neue JEPs eingerichtet

Java 10 & Beyond: Diese fünf Features erwarten uns

Hartmut Schlosser
Java 10 Beyond

(c) Shutterstock / Photon photo

 

Wie sieht die Zukunft von Java aus? Im neuen OpenJDK-Projekt Amber werden die Features gesammelt, die in Java 10 und späteren Java-Versionen umgesetzt werden sollen. Welche Neuerungen stehen in der Pipeline?

Das Feature-Set für Java 9 kennen wir – doch wie geht es danach weiter? Welche Neuerungen in Java 10 und noch späteren Java-Versionen enthalten sein werden, beginnt sich jetzt schon abzuzeichnen. Denn mit dem neuen OpenJDK-Projekt Amber hat Java-Spracharchitekt Brian Goetz nun eine konkrete Anlaufstelle für zukünftige Java-Erweiterungen geschaffen.

Dabei soll es wohlgemerkt um mehr gehen als bloßes Brainstorming: Hier werden JEPs angesiedelt, die bereits eine breite Zustimmung in der Community genießen. Und einige prickelnde Features sind bereits in Sicht!

Java 10 & Beyond: Was ist vorgesehen?

Allgemein geht es im Projekt Amber um Erweiterungen von Java, die die Produktivität bei der Java-Entwicklung verbessern sollen. Damit erinnert Amber an das sogenannte Project Coin, das schon in Java 7 für kleine Sprachverbesserungen wie Strings in Switch und numerische Literale gesorgt hatte.

In seiner Mitteilung an die OpenJDK-Mailingliste nennt Goetz bereits fünf konkrete Neuerungen für zukünftige Java-Versionen. Drei bereits offiziell existierende JEPs sind dabei:

Neben diesen sind zwei seit langem diskutierte Features für Project Amber vorgesehen: Daten-Klassen und Pattern Matching.

Wir schauen uns diese 5 Neuerungen einmal etwas genauer an.

Angular - Eine Einführung

Angular – eine Einführung

Manfred Steyer

In diesem Videotutorial erklärt Manfred Steyer alles, was man für einen professionellen Umgang mit Angular benötigt und zeigt anhand eines praxisnahen Beispiels, wie man Services und Dependency Injection integriert, Pipes zur Formatierung von Ausgaben nutzt, Komponenten mit Bindings verwendet, Angular-Anwendungen mit Modulen strukturiert und Routing gebraucht.

Konkret: Local Variable Type Inference

In JEP 286 geht es darum, die Typen-inferenz von Java auf Deklarationen lokaler Variablen zu erweitern. Die oft unnötige Manifest-Deklaration für lokale Variablen-Typen würde damit entfallen. Deklarationen der folgenden Art wären möglich:

var list = new ArrayList<String>();  // infers ArrayList<String>
var stream = list.stream();          // infers Stream<String>

JEP 301: Enhanced Enums

JEP 301 kümmert sich um eine Verbesserung des enum-Konstrukts. So sollen generische enums eingeführt werden, die Typen-Variablen enthalten können. Zudem sollen stärkere Typen-Checks für enum-Konstanten durchgeführt werden.

Im Ergebnis werden enums dadurch mit Konstanten-spezifischen Zuständen, Verhaltensweisen und Typen-Informationen ausgestattet, was u.a. viele Refaktorisierungen von enums in Klassen obsolet machen würde.

enum Argument<X> { // declares generic enum
   STRING<String>(String.class), 
   INTEGER<Integer>(Integer.class), ... ;

   Class<X> clazz;

   Argument(Class<X> clazz) { this.clazz = clazz; }

   Class<X> getClazz() { return clazz; }
}

Class<String> cs = Argument.STRING.getClazz(); //uses sharper typing of enum constant

 

JEP 302: Lambda Leftovers

Über die sogenannten Lambda Leftovers haben wir bereits berichtet. Das Wichtigste hier zusammengefasst:

Verbesserte Disambiguierung von Lambdas

Der Compiler soll das Target einer Lambda-Methode oder einer Methoden-Referenz auch in Situationen erkennen, in denen Überladungen auftreten.

Ein Beispiel:

m(Predicate<String> ps) { ... }
m(Function<String, String> fss) { ... }
 
m(s -> false) //ambiguous

Für Entwickler ist zwar leicht ersichtlich, welche überladene Methode hier vom Compiler gewählt werden sollte: Das Lambda gibt ein „false“ zurück, sodass  Function<String, String> nicht in Frage kommt.

Der Java-8-Compiler erkennt dies jedoch noch nicht. Solche und ähnliche Fälle sollen zukünftig durch erweiterte Disambiguitätschecks geklärt werden.

Nutzung des Underscores

Der Underscore _ wird in vielen Sprachen genutzt, um einen unbenannten Lambda-Parameter zu kennzeichnen. Dies soll nun auch in Java eingeführt werden.

Ein Beispiel:

BiFunction<Integer, String, String> biss = (i, _) -> String.valueOf(i);

Dies soll den Underscore unter anderem auch für die Kennzeichnung ungenutzter Methoden-Parameter frei machen.

Lambda Shadowing

In Java 8 dürfen Parameter von Lambda-Ausdrücken nicht dieselben Namen wie Variablen im sie umgebenden Scope tragen.

Map<String, Integer> msi = ...
...
String key = computeSomeKey();
msi.computeIfAbsent(key, key -> key.length()) //error

Im JEP 302 wird vorgeschlagen, diese Restriktion zu lösen und ein „Shadowing of lambda parameters“ zu erlauben.

Daten-Klassen

Ein momentan sehr heiß diskutiertes Thema sind die sogenannten Daten-Klassen. Worum geht es dabei?

Oft werden Klassen nur zu dem Zweck angelegt, um Daten zu halten. Ein Großteil der dafür notwendigen Codezeilen für beispielsweise Felder, Konstruktoren, equals,  hashCode, toString sind aber eigentlich unnötig. Mit der Einführung von Daten-Klassen in Java würde dieser Boilerplate-Code entfallen und vom Compiler direkt erledigt.

In der Sprache Kotlin, wo Daten-Klassen bereits existieren, sieht das folgendermaßen aus:

data class User(val name: String, val age: Int)

Der Compiler leitet hier von den Deklarationen des Hauptkonstruktors bereits Dinge wie das equals()/hashCode()-Paar und toString() in der Form „User(name=John, age=42)“ ab.

Wie stark sich die Java-Daten-Klassen diesem Kotlin-Modell annähern werden, ist zum jetzigen Zeitpunkt noch unklar. Mehr Informationen dürften dann verfügbar werden, wenn ein offizielles JDK Enhancement Proposal für Daten-Klassen in Project Amber vorliegt.

Pattern Matching

Das fünfte für Projekt Amber vorgesehene Feature ist das Pattern Matching. Dabei geht es um eine Alternative für die bisher in Java verfügbaren Bedingungssteuerungen if/else und switch.

Auch hier stehen andere Sprachen wie Kotlin, Haskell und Scala Pate, in denen Pattern Matching bereits etabliert ist. Wir betrachten das Beispiel von Alexander Hanschke aus dem Kotlin-Tutorial auf JAXenter:

 

fun check(param: Any): Any {
    return when(param) {
        is Int -> param in 0..100
        is String -> param.reversed()
        else -> {
            println("param unknown")
            return "unknown"
        }
    }
}

Im Beispiel verwendet die Funktion check einen Parameter des Typs Any. Der Ausdruck when dient dazu, um auf diesem Parameter bestimmte Konditionen zu prüfen, beispielsweise, ob der Parameter vom Typ Int ist. Ist das der Fall, wird überprüft, ob der Wert in dem Bereich 0 bis 100 enthalten ist. Diese Überprüfung nutzt Kotlins Smart Cast – der Compiler erkennt, dass der Typ innerhalb der Bereichsüberprüfung vom Typ Int ist und castet ihn automatisch.

Dasselbe gilt für die zweite Abfrage: Nach der Überprüfung auf den Typ kann anschließend direkt darauf zugegriffen werden, ganz so als handele es sich um einen String. Trifft keine der Bedingungen zu, wird ein Default-Zweig angegeben, der alle Eventualitäten abfängt. Innerhalb der Zweige können neben einfachen Ausdrücken auch ganze Blöcke angegeben werden.

In Projekt Amber werden für Java nun ebenfalls Möglichkeiten des Pattern Matching erforscht, die mit Typen und komplexen Konditionen funktionieren sollen. Wie das in Java aussehen könnte, hat Brian Goetz bereits in diversen Talks demonstriert:

// maybe in the future
String formatted = switch (constant) {
    case Integer i -> String.format("int %d", i);
    case Byte b: //...
    case Long l: // ...
    // ...
    default: formatted = "unknown"
}

Innovationsspirale Java

Soweit also unser Blick in die Zukunft von Java. Wer in Tuchfühlung mit Projekt Amber bleiben möchte, kann die Diskussionen auf den neu eingerichteten Mailing-Listen verfolgen:

  •  amber-dev — for discussing or contributing to the implementation of the Amber features, and to report user experience with the prototype.
  • amber-spec-experts — for Expert Group discussions of the design and specification of the Amber features. Traffic from spec-experts is automatically forwarded to spec-observers.
  • amber-spec-observers — for public discussion of the design and specification.
  • amber-spec-comments — the „suggestion box“.

Betonen muss man allerdings, dass eine konkrete Release-Roadmap für Projekt Amber noch nicht vorliegt. Ob wir also bereits in Java 10 in den Genuss dieser Features kommen werden, steht noch in den Sternen. Brian Goetz hält sich dazu bedeckt:

None of these features are currently targeted at any specific version of the Java platform; when ready, they will be proposed for targeting via the JEP process.

Java 10 Wishlist

Ebenfalls nicht vergessen werden darf, dass Projekt Amber nicht sämtliche Neuerungen für Java abdecken soll. Wie erwähnt geht es um kleine, Produktivitäts-fördernde Spracherweiterungen.

Weitere Features für Java, wie beispielsweise die Projekte Valhalla und Panama stehen ebenflass in der Pipeline. Geht es bei Projekt Valhalla um Anpassungen des Memory Layout der Java Virtual Machine (JVM) an die Anforderungen moderner Hardware (u.a. GPUs), kümmert sich das Projekt Panama um die Verbindung zwischen JVM und nicht Java-APIs. (Aktuelle Infos zu Panama finden sich in diesen Slides von Christoph Engelbert).

Und auch damit ist der Ideenraum für Java-Innovationen längst nicht erschöopft. Wir haben drei Community-Vertreter gefragt, welche Neuerungen in Java 10 für sie relevant wären:

A first cut of value types will be amazing. Official replacements for the ’safe‘ parts of sun.misc.Unsafe would also be most welcome. And the Shenandoah GC algorithm. Martijn Verburg

The hope is that we will see some new language features around the concept of „data classes“ – removing the need to manually write equals, hashCode, toString and getters. Such a feature would make day to day development much more pleasurable.
Stephen Colebourne

Eine hilfreiche und produktive Neuerung in Java 10 wäre es, die im JDK 8 eingeführten Optionals konsequent und als Sprachfeature umzusetzen. Möglich wäre z. B. eine Kombination aus dem Elvis-Operator, @Nullable / @NotNull Annotationen oder evtl. sogar Operator-Chaining (analog zur Swift-Programmiersprache), was vom Compiler schon verifiziert und in Bytecode umgesetzt werden würde. Das würde das Feature der „Nullvermeidung“ auf Sprachebene heben und deutlich mehr Möglichkeiten eröffnen.
Andere Bereiche, die ich für sinnvoll halte, betreffen die Integration von Java-EE-Standards, die heute exzessiv genutzt werden, in das JDK, wie z. B. JSON-Support und den sehr guten JAX-RS HTTP Client. Diese Standards sind heute sehr weit verbreitet, müssen jedoch immer als externe Abhängigkeiten eingebunden werden. Denkbar wäre z. B. Integration von JSONB / JSONP und JAX-RS (Client). Sebastian Daschner

Man sieht: Die Innovationsspirale für Java dreht sich weiter – eine gute Nachricht für alle, die am Java-Tropf hängen. Wem die Spirale zu langsam ist, der wende sich vertrauensvoll an andere JVM-Sprachen.

Was die so alles können, erzählen wir auf JAXenter derzeit in unserer Serie Pirates of the JVM.

Pirates of the JVM – die Infografik

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.
Kommentare
  1. Simon Wirtz2017-04-06 21:54:03

    Viele Features die andere JVM-Sprachen wie Kotlin schon heute vorzeigen. Warum noch an Java festhalten?

Schreibe einen Kommentar

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