Nach dem vierten Proposal (http://www.javac.info/closures-v04.html) für Closures von Gilad Bracha, Neal Gafter (der mit dem Java-Puzzlers), James Gosling und Peter von der Ahé (nach seiner Whishlist unter http://blogs.sun.com/ahe/entry/java_se_7_wish_list werden weitere abgefahrene Sachen möglich sein) wird in der Community heftig diskutiert, ob Closures nötig sind. Ich finde sie toll! Zwar sehe ich schon meine Teilnehmer über den Ausdrücken brüten und zweifeln an der Aussage „Java ist eine einfache objektorientierte Programmiersprache“ zweifeln, doch denke ich, dass es unausweichlich ist, Java mehr sprachliche Möglichkeiten zu bieten.
Java: A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, dynamic language […] Java omits many rarely used, poorly understood, confusing features of C++ that in our experience bring more grief than benefit. [http://java.sun.com/docs/overviews/java/java-overview-1.html]
Dass Java im Moment so viele Veränderungen erfährt ist vielleicht auch eine Frage der Wahrnehmung. Sun war mit Grammatikänderungen bisher sehr konservativ und seit mehr als 10 Jahren haben wir bis auf den Wechsel von Java 1.0 auf Java 1.1 und Java 1.4 auf Java 5.0 kaum Änderungen gesehen; strictfp/Sprachänderungen wäre man so ein Außenseiter. Nun gibt es stärkere Veränderungen, wie wir sie bei anderen Sprachen auch erleben. C# hat sich in den letzten Jahren unglaublich verändert — was als Java-Klon begann, ist heute eigenständig und als Sprache hoch innovativ. Mitunter starke strukturelle Änderungen lassen sich auch bei Skriptsprachen ausmachen, etwa Python (trinärer Operator, try/except/finally), PHP (die ganzen OOP-Eigenschaften), Perl (für Perl 2.6 ebenfalls Änderungen der OOP-Schreibweise/perl6-language-objects und funktionale Programmierelemente geplant) aber auch C++ und SQL. Als Java-Entwickler hat uns Sun nur in den letzten Jahren so „erzogen“ dass es kaum große Änderungen gab, was sich nun ändert. Hier muss Sun uns also wieder „umerziehen“.
Dass Java keine einfache Programmiersprache ist, müsste jedem eigentlich bewusst geworden sein, der didaktisch versucht, Konzepte wie Generics zu vermitteln. Unternehmen müssen auch mit nicht-Cracks Software entwickeln können und können nicht darauf bauen, dass alle Mitarbeiter Spezifikationen lesen und Best-Practices befolgen. (IMHO kann man mit OOP-Spezialisten in jeder Programmiersprache exzellente Ergebnisse erziehlen.) Eine Sprache muss daher auch immer ein bisschen Narrensicher sein. (Ein kleiner Seitenhieb auf Perl, der Sprache, der man „Write Once Read Never“ (WORN) nachsagt.) Da sehe ich in Closures auf jeden Fall ein Problem, denn während Generics doch noch einfach zu lesen sind (von der Deklaration sprechen wir nicht!) sieht das bei Closure-Nutzungen etwas anders aus. Hier muss der Java-Entwickler wieder eine neue Syntax lernen.
Bisher ist in der neuen Syntax kein Wort von neuen Schlüsselwörtern. Das macht die Anwendung einfacher als es bei Java 5 mit enum war. Ein weiterer Punkt ist, dass man über allgemeine Closures Dinge schreiben kann, die wie spezielle Lösungen aussehen. Ein häufig zitiertes Beispiel ist der Lock:
withLock( lock ) {
System.out.println( "Closures in Java 7" );
}
Das ist eine Kurzform für
withLock( lock, {=>
System.out.println( "Closures in Java 7" );
} );
Es ist gerade nicht withLock() ein spezielles Java-Konstrukt, sondern nur die Anwendung eines allgemeinen Closures. Intern wird das Umgesetzt über übliche Schnittstellen. Und mit { => } sieht man schon, wie Closures in Java aussehen können.
In der Summe finde ich Closures toll und freue mich schon. Zwar habe ich schon die ersten Ideen, wie man das didaktisch umsetzen kann, aber mal sehen, was bis dahin geschrieben wird. Was Madbean unter http://madbean.com/2006/closure/ zeigt, finde ich schon nett. Doch bis Java 7 „freigelassen“ wird, dauert es noch. Wer sich schon einmal vorbereiten möchte, der sollte sich zum Beispiel die Präsentation von Neal Gafter unter http://www.bejug.org/confluenceBeJUG/display/PARLEYS/Closures+for+Java anschauen.
Vielen Dank, ein Beitrag, wo man auf jedemfall sehr schöne informationen finden kann. Auch die weitere Beiträge die Sie am Ende ihrem Artikel hier vorgeschlagen haben, habe ich kurz angeschaut und die sind auch ziemlich interessant aus
Ich finde das Thema Closures in Java äußerst spannend und zugleich kontrovers. Es ist interessant zu sehen, wie Closures die Programmierung flexibler und ausdrucksstärker gestalten können. Allerdings stellt sich die Frage, ob die Komplexität, die sie mit sich bringen, wirklich notwendig ist. Oftmals habe ich festgestellt, dass Entwickler, die mit Closures arbeiten, mehr Zeit mit der Fehlersuche verbringen, da die Syntax und die Funktionsweise nicht immer intuitiv sind. Dennoch glaube ich, dass Closures in den richtigen Händen ein mächtiges Werkzeug sein können. Ich bin gespannt auf die Entwicklungen und wie sich die Community dazu positionieren wird!