Verschlüsse in Java 7

Question

Also wird Java 7 endlich die Schließungen bekommen? Was gibt es Neues?

Answer 1

http://java.dzone.com/news/closures-coming-java-7

Answer 2

Die neuesten Nachrichten sind AFAIK noch ab Ende November 2009, die Schließungen in Java 7 in irgendeiner Form sein werden. Da dies der Hauptgrund für eine signifikante Verzögerung bei der Veröffentlichung war, scheint es ziemlich unwahrscheinlich, dass sie es wieder fallen lassen werden.

Answer 3

Ja, Schließungen wurden enthalten, Plan von Java 7 zu veröffentlichen (und es war der wichtigste Grund, die Freigabe von Winter bis Herbst zu verzögern (voraussichtlich im September 2010)). Die neuesten Nachrichten finden Sie unter Project Lambda. Vielleicht interessiert Sie auch lesen latest specification draft.

Answer 4

Es gab eine ganze Reihe von Debatten über Syntax und Transparenz (vor allem, wie schwer es ist, eine Curry-Funktion mit einer bestimmten Syntax zu lesen, scheint es) auf der Mailingliste lambda-dev weiterzugehen ein paar Entwürfe von Vorschlagsiterationen von Sun, aber ich habe von ihnen auf dieser Liste nicht viel gesehen.

Answer 5

Im Moment gibt es keine offizielle Stellungnahme zum Zustand der Schließungen.

Hier sind some readable examples wie es funktionieren und aussehen könnte.

Wenn Sie einen Einblick bekommen wollen, was los ist, verweise ich auf die OpenJDK mailing list.

Übersicht

Grundsätzlich gibt es etwas Hoffnung, weil Code zusammen mit einigen Tests bereits zu einem gewissen Quellcode Zweig begangen wurden und es gibt zumindest einige halbwegs funktionierende Infrastruktur zu testen.

Die Änderungsnachricht von Maurizio Cimadamore lautet:

anfängliche Lambda-Push; der aktuelle Prototyp suuports folgende Merkmale:

• Funktionstypen Syntax (optional mit -XDallowFunctionTypes aktiviert)
• Funktionstypen
• volle Unterstützung für Lambda-Expression von Typ 1 und 2
• Inferenz geworfen Typen Subtypisierung/Rückgabetyp in einem Lambda
• Lambda-Konvertierung mit Regeln in v0.1.5 Entwurf
• unterstützt Referenzen auf 'dies' (sowohl explizit als auch implizit)
• Übersetzung Methode behandelt

Das modifizierte Skript Build des langtools Repository nun eine zusätzliche jarfile genannt javacrt erzeugt.jar , das eine Hilfsklasse enthält, die während der SAM-Konvertierung verwendet wird; nach dem zu bauen, das generierte Skripte javac/java kümmern die erforderlichen Abhängigkeiten automatisch so zusammengestellt werden, dass Code enthält Lambda-Ausdrücke Einrichtung und ausgeführt.

Aber das ist laufende Arbeit und ziemlich Buggy im Moment. Zum Beispiel stürzt der Compiler manchmal mit gültigen Ausdrücken ab, kompiliert keinen korrekten Closure-Syntax-Code oder erzeugt unzulässigen Byte-Code.

Auf der negativen Seite gibt es some statements von Neal Gafter:

Es ist schon fast drei Monate seit dem 0,15 Entwurf, und es ist jetzt weniger als zwei Wochen vor dem TL (Tool und Sprachen) endgültige Integration vorgehende openjdk7-Funktion abgeschlossen. Wenn Sie Fortschritte bei der Spezifikation und Implementierung gemacht haben, würden wir es sehr schätzen, dass es uns mitgeteilt wurde. Wenn nicht, können wir vielleicht helfen. Wenn Oracle entschieden hat, dass diese Funktion nicht mehr wichtig für JDK7 ist, wäre das auch gut zu wissen . Was auch immer geschieht, die Stille sendet die falsche Botschaft.

A discussion zwischen Neal Gafter und Jonathan Gibbons:

Große, das zu sehen, Maurizio! Leider kommt es eine Woche zu spät, und im falschen Repository, um in jdk7 aufgenommen zu werden.

Ich stelle fest, dass keiner der Tests eine Variable des Funktionstyps zeigt, der in einen SAM-Typ konvertiert wird. Was sind die Pläne dort? Jonathan Gibbons' response: Seit der veröffentlichten Feature-Liste für JDK7 und den veröffentlichten Zeitplan für JDK7 erscheinen würde im Widerspruch sein, warum übernehmen Sie immer den Zeitplan korrekt ist? Neal Gafter's answer: Da erinnere ich mich an wiederholte Diskussion dahingehend, dass das Feature-Set basierend auf ihrem Abschlussstatus in Bezug auf den Zeitplan angepasst werden würde.

Einige Leute sogar fragen, ob das Ganze Sinn macht mehr und suggest moving to another language:

Man beginnt sich zu fragen, warum nicht nur zu Scala bewegen - es viel mehr ist, die hinzugefügt werden muss zu Java, um eine kohärente Kombination von Features um Lambdas zu bauen. Und jetzt diese Verzögerungen, die nicht nur Benutzer von ParallelArray, sondern alle, die sauber refaktoriert, testbare Software in Java erstellen möchten.

Scheint, als ob niemand vorschlägt, Deklaration-Site-Varianz in Java hinzuzufügen => bedeutet FunctionN<T, ...> Schnittstellen nicht Subtype, wie sie sollten. Es gibt auch keine Spezialisierung für Primitive. (Scala @specialized ist für alle, aber Spielzeug Klassen gebrochen, aber zumindest ist es in der rechten Richtung bewegt)

Keine JVM-Ebene Anerkennung, dass ein Objekt ein Verschluss ist, und kann daher seine beseitigt, so kann es Seien Sie mit Scala Schließung Beseitigung (wenn die HOF kann auch inline sein.) Die JVM scheint etwas wie eine unvermeidliche Maschine hinzufügen Wort Zugriff auf jede polymorphe Call-Site, auch wenn sie angeblich inline-cached und nicht megamorph, auch im Inneren eine Schleife. Das Ergebnis, das ich gesehen habe, ist ungefähr eine 2x Verlangsamung auf Spielzeug Mikrobenchmarks wie "sum ein Array von ganzen Zahlen", wenn mit irgendeiner Form von Verschlüsse anders als etwas , das @ inline'd in Scala sein kann, implementiert. (Und sogar in Scala, die meisten HOFs sind virtuell daher nicht inline.) Ich für eine würde gerne sehen, inline in einer Sprache, die/ermutigt/die Verwendung von Verschlüsse in jeder for-Schleife.

Fazit

Dies ist nur ein kurzer Blick auf das ganze Problem los und die Zitate und Aussagen überhaupt keinen Anspruch auf Vollständigkeit. Im Moment sind die Leute immer noch in dem Zustand "Können Schließungen wirklich in Java gemacht werden und wenn ja, wie sollte es gemacht werden und wie könnte es aussehen?".

Es gibt kein einfaches "OK, wir fügen nur Schließungen zu Java über dem Wochenende hinzu". Aufgrund der Interaktion von einigen Design-Fehlern wie Varargs als Arrays, schreiben Sie Löschen ... es gibt Fälle, die einfach nicht funktionieren können. All diese kleinen Probleme zu finden und zu entscheiden, ob sie reparierbar sind, ist ziemlich schwierig.

Am Ende könnte es einige Überraschungen geben. Ich bin mir nicht sicher, was das überrascht sein wird, aber ich denke, es entweder sein:

• Verschlüsse werden nicht in Java 7 oder
• Closures in Java 7 erhalten wird, was Generics in Java waren 5 (Buggy, komplexe Dinge, die aussehen wie es funktionieren kann, aber brechen auseinander, sobald Sie die Dinge ein wenig weiter schieben)

Persönliche Meinung

ich Scala geschaltet vor langer Zeit. Solange Oracle der JVM keine dummen Dinge antut, ist mir das egal. Im evolutionären Prozess der Java-Sprache wurden Fehler gemacht, teilweise aufgrund der Rückwärtskompatibilität. Dies verursachte eine zusätzliche Belastung mit jeder neuen Veränderung, die die Leute versuchten zu machen.

Grundsätzlich: Java funktioniert, aber es wird keine Weiterentwicklung der Sprache mehr geben. Jede Änderung, die Menschen vornehmen, erhöht die Kosten für die nächste Änderung, so dass Änderungen in Zukunft immer unwahrscheinlicher werden. Ich glaube nicht, dass es nach Java 7 irgendwelche Änderungen in der Java-Sprache geben wird, abgesehen von einigen kleinen Syntaxverbesserungen wie dem Projekt Coin.

Answer 6

Ich bin auf einer Freigabekonferenz jetzt und der Sprecher sagt, dass Verschlüsse zu Java 8 kommen.