#devoxx 09: map&reduce und closures

1 Kommentar

Eines der meistdiskutierten Themen auf der diesjährigen Devoxx sind die demnächst erscheinenden Javaversionen und die darin enthaltenen Änderungen. Natürlich ist es nett, daß es mit Java 7 möglich sein wird einen switch() mit Strings durchzuführen, oder daß die Platform modularisiert wird. Aber der Hype um Closures ist mir unverständlich. Java 7 wird sogar extra dafür verzögert. Was soll also der Hype?

Closures sind nicht trivial zu erklären. Ich versuche das deshalb auch garnicht und vereinfache sie mal zu Codeblöcken welche Leben eingehaucht bekommen. Dadurch können Closures einen ausserhalb nicht mehr existierenden Zustand referenzieren.

Closures sind ohne Zweifel nett. Ich programmiere gerne in Closures wenn ich JavaScript code schreibe. Auch Clojure hat mir sehr zugesagt als ich es in Howard Lewis Ships Vortrag näher kennenlernte. Wenn man über Clojure spricht ist auch eines klar: Es ist eine neue Sprache welche ihre eigenen Konzepte und Mechanismen mitbringt. Java zu verstehen und zu können hilft nicht für Clojure, obwohl Clojure interoperabel mit Java ist. Java mit Closures ist hingegen komisch. Der durchschnittliche Java Entwickler wird seine Schwierigkeiten haben Closures zu verstehen, und erst recht keinen Anwendungsfall haben sie einzusetzen. Der Grund ist daß dise Art der Programmierung ein anderes Verständnis vorrausetzt.

Und das ist map&reduce. Ok, es ist jetzt nichts fundamental anderes, und auch kein Grundkonzept, dennoch ist map&reduce ein guter Anwendungsfall. Es wurde in fast jeder Session angesprochen und verspricht die Antwort auf die Frage nach der Skalierbarkeit zu sein. Es vereinfacht viel, da es nur funktioniert wenn man vereinfacht. Um Gregor Hohpe zu zitieren: „if we would have rebuilt a relational database, just to make it faster, we would have failed“. Das ist sicherlich wahr. Die inherente Komplexität einer relationalen Datenbank ist nunmal so daß sich das Problem nicht optimieren lässt. Wäre dies möglich hätte Oracle das sicher bereits getan.

Also muss man vereinfach, aber wie? Behandelt Daten als Schlüssel Wert Tupel, so wie in den Cobol Copystrecken. Man benötigt doch garkeine Relationen. Sie machen alles nur kompliziert und fügen kaum Wert hinzu.

Wenn man diesen Schritt gemacht hat kann man sowohl mit als auch ohne Closures skalierbar entwickeln. Natürlich favourisieren die „neuen“ dieses Pattern indem sie Code anbieten der jeweils auf einem Datensatz arbeiten kann.

Gregor zeigte einige bei Google eingesetzte Muster und Frameworks. Besonders gefiel mir Sawzall, welches scheinbar noch nicht open sourced wurde. Es ist sehr beschreibend und äußerst präzise in der Formulierung was mit einem Datensatz zu geschehen hat. Es ist eigentlich eine einfache Closure:

errorcount table sum of int
--------
if contains input 'error'
  emit errorcount <- 1

Man kann die aktuellen Trends nur als Aufruf verstehen sich über die aktuellen Problemlösungen Gedanken zu machen. Wahrscheinlich benötigen wir neue Muster und Konzepte, da sich Bestehende nicht weiter optimieren lassen. Wir brauchen etwas Neues. Ob dafür Closures in Java ausreichend sind bleibt zu sehen.

Fabian Lange ist Lead Agent Engineer bei Instana und bei der codecentric als Performance Geek bekannt. Er baut leidenschaftlich gerne schnelle Software und hilft anderen dabei, das Gleiche zu tun.
Er kennt die Java Virtual Machine bis in die letzte Ecke und beherrscht verschiedenste Tools, die JVM, den JIT oder den GC zu verstehen.
Er ist beliebter Vortragender auf zahlreichen Konferenzen und wurde unter anderem mit dem JavaOne Rockstar Award ausgezeichnet.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • hansi

    schon allein wenn man closures _nur_ als ersatz für interfaces mit einer methode betrachtet ist mir die neue ästhetik und vor allem lesbarkeit durchaus eine kleine verzögerung wert.

    das mit lambda-kalkül viele probleme kurz und präzise gelöst werden können wird für dich als mathematiker wahrscheinlich keine überraschung sein.
    (in mathematica: lowercase /@ liste, stell dir einfach den zugehörigen java-code vor…)

    nun gut, closures sind nicht alles. aber für mich ist es definitiv ein schritt in die richtige richtung!

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.