Bericht: Wird Java 8's Lambda das Gesicht der Welt verändern?

Java 8 wird in weniger als einem Jahr ausgeliefert werden. Eines der wichtigsten Projekte, die mit dieser Version erscheinen werden, ist sicherlich das Lambda-Projekt, das als JSR335 bezeichnet wird und von Brian Goetz geleitet wird. Dieses Projekt zielt darauf ab, Ihnen eine einfachere Möglichkeit zu bieten, funktionale Programmierung und paralleles Rechnen zu integrieren. Ziel ist es, die Produktivität von Entwicklern zu steigern, indem die Ausdrucksfähigkeit der Sprache verbessert wird, und die Leistung von Java-Anwendungen zu optimieren, indem eine einfachere Möglichkeit zur Nutzung von Multi-Core-Architekturen geboten wird. Aber wie werden sich die Ergebnisse des Project Lambda auf die Java-Community auswirken?

Ich bin Mitglied von Xebia Frankreich. Wie Xebia Niederlande widmen wir jeden Monat einen Tag dem Wissensaustausch (auch XKE genannt - Xebia Knowledge Exchange). Ich habe die Gelegenheit des XKE im Oktober genutzt, um eine Sitzung vorzuschlagen und meine Kollegen zu fragen: Werden die vom Lambda-Projekt eingebrachten Änderungen schließlich von der Java-Welt - einschließlich der Java-Gemeinschaft und der Projekte in den Unternehmen - angenommen oder werden diese Änderungen abgelehnt werden? Die Sitzung hatte einen etwas provokanten Titel: "Wird Java 8's Lambda das Gesicht der Welt verändern?"

Publikum

Bei dieser Sitzung waren 16 Xebianer anwesend, darunter einer unserer beiden CTOs und ich selbst. Im Allgemeinen bestand das Publikum aus Java-Programmierern mit einer Erfahrung in dieser Sprache zwischen 2 und 10 Jahren und sogar mehr. Viele von uns kennen sich auch mit anderen Programmierparadigmen aus (z.B. mit funktionaler Programmierung).

Inhalt der Sitzung

Die 3-stündige XKE-Sitzung war um eine Präsentation herum aufgebaut. Es folgten Sequenzen von Live-Coding und Debatten. Die Sitzung endete mit einer Retrospektive.

Präsentation

Die Sitzungspräsentation über das Projekt Lambda war in drei Hauptabschnitte unterteilt. Sie begann mit einem Abschnitt, der den Kontext des Project Lambda (Optimierung für Multi-Core-Architekturen und Verbesserung der Produktivität von Entwicklern) und seine Motivation beschrieb. Dann zeigte ich den Zuhörern einen Abschnitt über die Lambda-Ausdrücke in Java 8, die virtuellen Erweiterungsmethoden und auch die Methodenreferenzen, die Erweiterung der API-Sammlung im JDK und wie einfach es werden wird, nebenläufige Prozesse zu erstellen. Ich habe mit einem Abschnitt abgeschlossen, der die Art und Weise beschreibt, wie das Projekt verwaltet wird, und seine Beziehung zur Community (Teammitglieder des Project Lambda, Websites, Mailinglisten, begeisterte Menschen (insbesondere in Frankreich), die sich an der Förderung des Project Lambda beteiligen). Ich habe auch meine eigene Einschätzung der Beziehung zwischen dem Projekt Lambda und der Gemeinschaft eingebracht.

Live-Codierung und Debatten

Der Live-Coding-Teil bestand aus einer Reihe von Übungen auf der Grundlage von Unit-Tests. Die ersten drei Übungen zeigten die Unterschiede zwischen imperativem Java, Guava und der Verwendung von Lambda-Ausdrücken in Java 8 im Hinblick auf die Verarbeitung von Sammlungen. Dann erfuhren wir, dass Lambda-Ausdrücke dabei helfen, die Begriffe call-by-value und call-by-name in Methodenaufrufen auszudrücken. [caption id="attachment_10084" align="alignleft" width="300"] Live-Codierung und Debatten[/caption] Wir haben eine Übung verwendet, die Martin Odersky (Schöpfer von Scala) auf den ScalaDays'2011 vorgeschlagen hat. Da wir wissen, dass jede Taste auf einem Telefon mit Mnemonics verbunden ist (z.B. für die Taste '2' gibt es die Mnemonics 'A', 'B' und 'C'), zielte die Kata darauf ab, das Verhalten der Autovervollständigung beim Schreiben einer SMS zu reproduzieren. Als nächstes haben wir eine Reihe von Übungen zu den virtuellen Erweiterungsmethoden, ihrer Verwendung und der Art und Weise, wie sie das Diamantenproblem lösen, durchgeführt. Ich habe auch die Optimierungen vorgestellt, die für die Lambda-Ausdrücke vorgenommen wurden, die vom Zustand der anderen Teile der Anwendung unabhängig sind. Wir schlossen mit einem Mikro-Benchmark über die Verarbeitung großer Sammlungen ab, indem wir einerseits die sequenziellen und andererseits die parallelen Operationen verwendeten. Wir haben festgestellt, dass die parallele Version auf einer Quad-Core-Architektur einen Leistungsgewinn bringt und wie einfach es war, diesen Gewinn zu realisieren. Dieser Teil der Sitzung hat sicherlich die meisten Reaktionen des Publikums hervorgerufen. Es gab viele Fragen, Überlegungen, Herausforderungen und auch... Trolle. Die Live-Codierung und die Debatten waren sicherlich einer der Teile der Sitzung, in denen die Zuhörer einen besseren Einblick in Java 8 erhielten. Es hat ihnen sehr geholfen, ihre Standpunkte mitzuteilen. Sie finden den Code, der während der Sitzung entstanden ist, auf github.

Rückblickend

Die Retrospektive basierte auf einem Geschwindigkeit Auto. A Speed Car erzählt die Geschichte eines Piloten, der ein möglichst leistungsstarkes Auto finden muss. Sein Ziel ist es, eine Brücke schnell zu überqueren. Die Brücke darf nicht einstürzen. Wenn der Pilot die andere Seite der Brücke erreicht, hat er sein Projekt erfolgreich abgeschlossen. [caption id="attachment_10176" align="alignleft" width="300"] Der Flitzer[/caption] Natürlich ist der Flitzer eine Metapher. Auf der einen Seite des Bildes steht der Auto-Fallschirm-Teil des Bildes für das Lambda-Projekt von Java 8 zum jetzigen Zeitpunkt, mit seiner neuen Syntax, der neuen Collection-API und der Art, wie das Projekt verwaltet wird. Genauer gesagt spiegelt das Auto die treibende Kraft hinter dem Projekt wider und der Fallschirm ist mit dem verbunden, was es tendenziell bremst. Auf der anderen Seite des Bildes steht der Teil mit der Brücke und dem Abgrund für die Zukunft des Lambda-Projekts. Mit anderen Worten, die Brücke ist das, was das Projekt am Laufen hält (die Gemeinschaft, die Annahme in Projekten usw.). Der Abgrund ist als eine teilweise oder sogar vollständige Ablehnung der neuen Funktionen von Java 8 zu sehen.

Foto der Ergebnisse der Retrospektive (auf Französisch)

[caption id="attachment_10178" align="alignleft" width="300"] Ergebnis auf dem Rennwagen und dem Fallschirm[/caption] [caption id="attachment_10179" align="alignleft" width="300"] Ergebnis am Abgrund[/caption] [caption id="attachment_10180" align="alignleft" width="300"] Ergebnis auf der Brücke[/caption]

Ergebnisse der Retrospektive und des Restes der Sitzung

Zum Abschluss der Sitzung finden Sie hier die Punkte, die von den Teilnehmern hervorgehoben wurden.

Bereitstellung eines Leitfadens mit bewährten Praktiken

Java 8 wird mit neuen Funktionen ausgeliefert werden. Diese Funktionen werden den Entwicklern helfen, ihre Produktivität zu steigern. Aber es ist leicht vorstellbar, dass sich schlechte Praktiken verbreiten werden, denn es wird sicherlich viele Entwickler geben, die nicht in der Lage sind, die Verbesserungen von Java 8 richtig zu nutzen. Idealerweise müssen die Entwickler angeleitet werden. Dies kann durch die Bereitstellung von Best Practices in einem Leitfaden geschehen.

Die neue Syntax ist schön, aber nicht für jeden geeignet

Die Vereinfachung der Syntax im Allgemeinen wurde von den Teilnehmern begrüßt. Die Mehrheit wünscht sich jedoch noch mehr Vereinfachungen, insbesondere bei den verketteten Ausdrücken. Zum Beispiel sind wir gezwungen, die Methode map in einer Ansicht aufzurufen, um eine Transformation durchzuführen, bevor wir reduce aufrufen. Dies wurde als "ungeschickter Ausdruck" empfunden. Das Gleiche gilt für den zwischengeschalteten Aufruf von stream: Warum sind die Operationen auf stream nicht direkt in den Sammlungen (List, Set, Map usw.)? Die aktuelle Syntax sieht aufgrund der Signatur der Operationen "map" und "reduce" wie folgt aus: [sourcecode language="java"] Streams.stream(myCollection) .map(produkt -> produkt.getUnitPrice() produkt.getQuantity()) .reduce(0.0, (subTotal, price) -> subTotal + price) [/sourcecode] Einige Leute haben jedoch nicht verstanden, warum wir die Operation "produkt.getUnitPrice() produkt.getQuantity()" von "subTotal + price" trennen müssen. Sie haben gesagt, dass die Trennung von "map" und "reduce" schwieriger zu lesen ist. Aus ihrer Sicht wäre es besser, diese Operationen zusammenzufassen, etwa so: [sourcecode language="java"] myCollection.reduce(0.0, (subTotal, price) -> subTotal + product.getUnitPrice() * product.getQuantity()) [/sourcecode] Es gab Bemerkungen über das Fehlen von impliziten Parametern wie "it" in Groovy oder "_" in Scala. Einige meinten, dass das Vorhandensein solcher Parameter wünschenswert wäre. Schließlich sind einige der Meinung, dass der Code nicht leicht zu lesen ist, insbesondere im Fall der Verkettung von map und reduce.

Die virtuellen Erweiterungsmethoden

Die virtuellen Erweiterungsmethoden stellen eine Möglichkeit dar, die bestehende API im JDK zu erweitern, ohne dass die bestehenden Implementierungen gezwungen sind, neuen Code für diese Erweiterungen bereitzustellen. Zum Beispiel wird die Collection-API von Java neue Methoden enthalten, um Massenoperationen durchzuführen und zu parallelisieren. Mit den virtuellen Erweiterungsmethoden ist Hibernate beispielsweise nicht gezwungen, alle neuen Erweiterungen der Collection-API für seine PersistentCollection neu zu implementieren. Aber werden die virtuellen Erweiterungsmethoden nicht für neue Verwirrung sorgen? Es ist beispielsweise möglich, eine Standardimplementierung einer Methode m einer Schnittstelle bereitzustellen und die Unterklassen nicht zu zwingen, m neu zu implementieren. In einem Vererbungsbaum ist es möglich, zwischen einer Standardimplementierung und keiner Implementierung abzuwechseln. Dies kann zu Verwirrung im resultierenden Verhalten von m führen. Einer der verbleibenden Kritikpunkte an Project Lambda ist die Art und Weise, wie Javadoc die virtuellen Erweiterungsmethoden behandeln wird. Da sie ein Verhalten in die Schnittstelle einführen, wird die entsprechende Javadoc kritisch.

Troll

Einer der Teilnehmer hat argumentiert, dass es zwangsläufig viele Trolle von Entwicklern geben wird, insbesondere von solchen, die auf funktionale Programmierung spezialisiert sind. Ein anderer Teilnehmer entgegnete, dass diese Trolle in gewissem Sinne Werbung machen werden, die die Neugierde der Entwickler wecken kann.

Andere Punkte

• Einige Mitglieder sind der Meinung, dass das Lambda in Java 8 zu spät kommt, da es derzeit viele andere konkurrenzfähige Lösungen gibt: Scala, Groovy, Clojure und sogar Guava für die Collection API.
• Die Lambdas in Java 8 sind in gewisser Weise anonyme innere Klassen und haben keinen eigenen Typ. Dies unterstreicht in gewisser Weise die Schuld von Java.
• Es scheint schwierig zu sein, die Ketten von Methodenaufrufen zu debuggen, wie filter(x -> ...).map(y -> ...).reduce((u, v) -> ...)
• Es wird interessant sein, die Ergebnisse von Benchmarks zwischen sequentiellen und parallelen Streams zu erhalten.
• Java 8 führt eine neue Syntax ein. Wird sich dadurch die Kompilierungszeit erhöhen?

Fazit

Es war eine spannende Sitzung. Die meisten Äußerungen und Überlegungen waren sehr interessant, auch wenn es einige Trolling-Bedenken gab. Sie haben es größtenteils verdient, berichtet zu werden. Das Format, das ich für diese Sitzung gewählt habe, hat dazu beigetragen, reichhaltige Reaktionen aus dem Publikum zu erhalten, auch wenn die zur Verfügung stehende Zeit relativ kurz war. Ich möchte Sie ermutigen, eine solche Sitzung zu organisieren.