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.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Fabian Lange
26.3.2015 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Fabian Lange
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.