Java: Vorschläge für Generics, Lambdas und Enumerations

Gerfried Steube on December 10, 2016 - 5:10 am in Software-Entwicklung

[ad_1]

Mark Reinhold hat drei JEPs vorgestellt, die für besser lesbaren Code bei eingegrenzent Generics sorgen, Enumerations um individuelle Typen erweitern und Mehrdeutigkeiten bei Lambdas verhindern sollen.

Mark Reinhold, Leiter der Entwicklungsabteilung der Java Standard Edition, hat drei JEPs (JDK Enhancements Proposals) mit den Nummern 300, 301 und 302 vorgestellt. Sie sollen vor allem für mehr Klarheit und besser lesbaren Code sorgen und für das JDK (Java Development Kit) sowie das OpenJDK gleichermaßen gelten.

Begrenzte Generics

Der erste Vorschlag betrifft Generics, genauer deren Eingrenzung auf bestimmte Kind- oder Elternklassen. Das JEP 300 bringt keine neue Funktionalität, verlagert aber die Art der Eingrenzung auf die Deklaration. Bisher können Entwickler die Begrenzung wahlweise dort über extends beziehungsweise super festlegen oder bei der Anwendung über <? extends Elternklasse> oder <? super Kindklasse>. Meist nutzen Entwickler die Begrenzung bei der Anwendung, da meist erst zu dem Zeitpunkt die konkrete Klasse zur Begrenzung feststeht. Oft lässt sich jedoch bei der Deklaration festlegen, ob die Generics auf Eltern- oder Kindklassen begrenzt sein sollen.

Im Interesse einer besseren Lesbarkeit schlägt das JEP vor, dass Entwickler in der Deklaration bestimmen können, welche Begrenzung erfolgt, und diese dann automatisch bei der Verwendung auf die konkrete Klasse genutzt wird. Nach den Codezeilen

interface Function<contravariant T, covariant R> {
 R apply(T arg);
}

behandelt der Compiler damit Function<String, Number> so wie in der bisherigen Schreibweise <? super String, ? extends Number>. Als alternative Schreibweisen innerhalb der Deklaration nennt das JEP <-R, +T> oder <in T, out R> vor.

Typzuweisung in Enumerations

Das JEP 301 schlägt vor, dass Konstanten innerhalb von Enumerations einen eigenen Typ haben können. So sind nach folgender Deklaration:

enum Pet<A extends Animal> {
 BELLA<Dog>(new Dog("Bella")),
 BUDDY<Dog>(new Dog("Buddy")),
 TIGGER<Cat>(new Cat("Tigger"));

 A animal;
 Pet(A animal) {this.animal = animal;}
 public A get() {return animal;}
}

die Elemente BELLA und BUDDY jeweils als Hund und TIGGER als Katze definiert und somit ein Zugriff auf die spezifischen Methoden beispielsweise als Pet.BELLA.get().bark(); möglich.

Eindeutige Lambdas durch Unterstriche

Der dritte Vorschlag mit der Nummer JEP 302 orientiert sich an anderen Programmiersprachen. Unterstriche in Lambdas sollen mehrdeutige Aufrufe verhindern, indem sie nicht genutzte Parameter ersetzen, wie in folgendem Beispiel:

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

Ebenso wäre es möglich, beide Variablen auszulassen, wenn das Lambda sie nicht benötigt. Damit geben Entwickler vor, dass die passende Methode zwei Parameter besitzt und schafft somit Klarheit, welche Methode gefragt ist. Die Umsetzung ist jedoch erst ab Java 9 möglich: Vor Java 8 durften Entwickler den Unterstrich als normalen Platzhalter auch innerhalb Lambdas verwenden. Mit Java 8 gibt es eine Warnung, und mit Java 9 sind Unterstriche verboten und damit als Platzhalter für nicht genutzte Parameter geeignet.

Weitere Details und Beispiele finden sich in einem Blogbeitrag auf Voxxed. Da JEPs als langfristige Änderungsvorschläge ausgelegt sind, wird die konkrete Umsetzung noch auf sich warten lassen. (rme)

[ad_2]