Keine Closures in Java 7 (?)

[tfa]

Wie es aussieht, wird es in Java doch keine Closures geben. Diese Info (Gerücht?) geistert jedenfalls gerade durch diverse Blogs und Foren. Eine offizielle Quelle habe leider nicht finden können.

http://www.dzone.com/links/no_closures_in_java_7.html

Ein bisschen Schade wär es schon, aber der Untergang der Welt ist das auch nicht. Man kann ja immer noch Groovy benutzen.

 

[ARadauer]

ja ja das closures thema.... ich bin dagegen ;-)

 

[Landei]

Das Gerücht scheint zu stimmen. Eigentlich voll daneben bei *drei* funktionierenden Varianten (incl. Implementierungen).

Ich denke, diese Entscheidung wird Java über kurz oder lang den Todesstoß versetzen. Closures mögen in einer Sprache wie Java nur häßlich zu implentieren sein, aber ohne sie lassen sich manche Dinge einfach nicht realisieren. Bei den Generics ist es ähnlich: Es ist schweinekompliziert, gute generische Klassen zu schreiben, aber kinderleicht, gut geschriebene generische Klassen zu *benutzen*

Ich benutze Closures inzwischen andauernd (und zwar in einer statisch getypten Sprache, ratet mal welche), und staune, wie ich jemals ohne auskommen konnte. Ohne Closures ist Java heutzutage einfach nicht "konkurrenzfähig", und die kommende Multicore-Revolution macht das Ganze noch viel akuter. C#, Groovy, Boo, Fan, Scala und Co. laufen Java mit Meilensteifeln davon. Schade.

 

[byte]

Ich denke, diese Entscheidung wird Java über kurz oder lang den Todesstoß versetzen.

Das denke ich nicht.

 

[Ebenius]

Das denke ich nicht.

Da schließe ich mich an.

 

[maki]

Worauf Landei wohl hinauswill ist die Tatsache, dass man mit Closures Aufgaben parrallelisieren kann (zB. für MultiCore Prozessoren), ohne zusätzlichen Aufwand.

So gesehen ist es natürlich ein riesen Nachteil keine zu haben.

 

[tfa]

Ich glaub auch, diese Befürchtung ist unbegründet. Es sind ja nicht die technikverliebten "Coder", die darüber zu entscheiden haben, ob Java eingesetzt wird oder was anderes. Und wer featuregeil ist, kann ja immer noch zum Lattenzaun greifen

 

[tfa]

Worauf Landei wohl hinauswill ist die Tatsache, dass man mit Closures Aufgaben parrallelisieren kann (zB. für MultiCore Prozessoren), ohne zusätzlichen Aufwand.

So gesehen ist es natürlich ein riesen Nachteil keine zu haben.

Da reichen aber Closures alleine nicht aus. Hierzu muss man schon durchgängig funktional programmieren. In funktionalen (meinetwegen auch multiparadigmen-) Sprachen geht das besser als im imperativen Java, so das diese Hoffnung sich auch mit Closures eh nicht erfüllen würde.

 

[byte]

Nicht der syntaktische Zucker ist entscheidend darüber, ob eine Sprache eine hohe Produktivität mitbringt. Es sind vielmehr die zur Verfügung stehenden Libraries, Frameworks, Tools und Technologien... und natürlich wie gut sich die Sprache in die jeweilige Systemlandschaft integrieren lässt.
Java ist einfach alt, das merkt man an vielen Ecken und Enden. Ich persönlich habe nichts gegen die Einführung neuer Sprachfeatures, aber es gibt auch berechtigte Zweifeln, ob das immer so sinnvoll ist. Meine Meinung: Die JVM wird uns noch für sehr lange Zeit erhalten bleiben. Ob in 10 Jahren aber noch Java als Sprache herhält oder Scala zum Produzieren von Bytecode benutzt wird, bleibt abzuwarten.

 

[Landei]

Gibt es irgendeine moderne Sprache aus der C++-Syntax-Familie ohne Closures außer Java? Fan verzichtet z.B. weitgehend auf Generics, hat aber Closures. Ich denke, die Bedeutung von Closures wird permanent unterschätzt. Sie sind viel mehr als "syntaktischer Zucker" und können auch nicht durch anonyme Klassen oder so "ersetzt" werden. Java strotzt vor Krüppellösungen (z.B. Iteratoren oder der for-each-Schleife), die ohne Closure nicht nötig wären. Code wird nicht da abgearbeitet, wo er eigentlich hingehört, Abstraktionsmöglichkeiten gehen verloren, Code wird unnötig wiederholt, Programme sind länger und schwerer zu verstehen.

Ich würde mir an eurer Stelle *genau* anschauen, was Closures eigentlich sind, und was man damit anstellen kann, bevor ihr entscheidet, dass man sie nicht braucht oder dass sie nicht so wichtig sind. Leute wie Gosling oder Gafter schlagen sowas nicht aus Dudeldei vor.
Exakt die gleiche Diskussion gab es schon einmal mit Generics. Würdet ihr etwa ohne Generics programmieren wollen? Ich denke nicht (trotz all der bekannten Schwächen der Java-Implementierung) .

 

[byte]

Ich programmiere immer wieder mal ohne Generics. Immer dann wenn ich in einem Projekt bin, wo noch Java 1.4 im Einsatz ist. Und davon gibts noch genug. Insofern seh ich das ziemlich entspannt. Ich fänds interessant, wenn Closures kommen. Und wenn nicht, dann kann ich damit auch leben.
Mein aktuelles Projekt hat erst kürzlich von Java 1.4 auf 5 umgestellt. Java 7 wird vorraussichtlich nie eingesetzt werden. Ich schätze mal, es wird vielleicht noch so 10 Jahre dauern, bis ein Großteil der Java Projekte mit Java 7+ arbeiten.
Wer weiss, ob dann nicht schon viele neueren Projekte mit Scala geschrieben sind.

 

[Landei]

Scala ist zur Zeit der aussichtsreichste "Thronerbe", aber ich bezweifle, dass es sich auf breiter Front durchsetzen wird. Zu viele Leute wollen nicht lernen, sondern nur "irgendwie" ihre Probleme gelöst haben. Außerdem ist die Syntax auf den ersten Blick abschreckend (war auch für mich so).

Dass inzwischen soviele Leute zu den dynamisch getypten Sprachen übergelaufen sind, ist zwar kein Wunder nach dem, was einem das Java-Typsystem zumutet, aber macht mir ehrlich gesagt Angst. Die Leute denken immer noch, ein Typsystem wäre "nur" dazu da, damit man sich nicht so leicht in den Fuß schießt, aber das ist so, als wenn man sagen würde, Teleskope wären nur dafür da, damit man sich die Augen nicht so anstrengt.

 

[foobar]

Closures in Java wären eine feine Sache, aber das zieht einen elenden Rattenschwanz nach sich, daher wird es wohl nicht dazu kommen.
Wenn man Closures in Java nutzen will kann man ja immer noch zu Groovy oder Scala greifen. Die lassen sich ja fast natlos in Java einbetten.
Closures sind ja nicht nur syntaktischer Zucker für anonyme Klassen, sondern setzen auch Ducktyping voraus und das wäre ein großer Paradigmenwechsel.
Da muß man sich eben genau überlegen was man will. Entweder die Sprache Java wird immer mehr ausgebaut bis niemand mehr durchblickt oder es gibt einfach einen Nachfolger. Für letzteres gibt es ja mittlerweile genügend Kandidaten, daher bin ich mittlerweile gegen große Veränderungen in der Sprache.

 

[Landei]

Closures sind ja nicht nur syntaktischer Zucker für anonyme Klassen, sondern setzen auch Ducktyping voraus und das wäre ein großer Paradigmenwechsel.

Wieso Ducktyping? Wäre mir aufgefallen, wenn Scala sowas hätte

 

[tfa]

Closures sind ja nicht nur syntaktischer Zucker für anonyme Klassen, sondern setzen auch Ducktyping voraus und das wäre ein großer Paradigmenwechsel.

Das hat nichts miteinander zu tun. Closures in Java hätten statische Typen gehabt, wie alles andere auch.

 

[foobar]

Und woher soll Java dann wissen welche Methode aufgerufen werden soll?
In Groovy geht das nur durch Ducktyping. Wie funktioniert das denn in Scala?

 

[Marco13]

Hab' den Begriff "Ducktyping" eben zum ersten Mal gelesen - kannte das Konzept GROB und in Ansätzen vom Hörensagen über Smalltalk. Nach dem Überfliegen des Wikipedia-Artikels stellt sich mir aber die Frage, ob das nicht (in Java) die trivialste Anwendung von reflection ist, die man sich vorstellen kann: getMethod("bla") - wenn's klappt, is' gut, wenn nicht, dann nicht. Ist natürlich syntaktisches Salz (als Gegenpart zum angesprochenen Zucker), aber doch prinzipiell möglich?! ???:L

 

[Landei]

Scala-Beispiel:

var sqrtSum = 0.0
List(9,16,4).foreach(sqrtSum += Math.sqrt(_)) 
//sqrtSum ist jetzt 9.0
val list = List(9,16,4).map(Math.sqrt(_))
//list ist die Liste (3.0, 4.0, 2.0)

1) Da ist kein Ducktyping. foreach auf eine Liste von A's angewandt verlangt z.B. eine Closure A -> void (oder "Unit" in Scala). map verlangt für einer Liste von A's eine Closure A -> B und liefert eine Liste von B's. Die zeite Closure hat dementsprechend den Typ Int -> Double
2) Eine Closure hat Zugriff auf umgebende Variablen (sqrtSum), was man nicht ohne weiteres mit anonymen Klassen hinbekommt
3) Das hier ist die Kurzschreibweise, man könnte die Closures auch ausführlich mit Parameternamen und Typbezeichnern schreiben. Meistens ist der Compiler aber clever genug, das allein hinzubekommen. Jede Variable und jedes Objekt hat immer einen Typ, und Closures machen da als ganz normale Objekte keine Ausnahme.