Brian Goetz, Entwickler an Java 7 bei Oracle, hat sich nun in der Frage zu Wort gemeldet, ob Closures nun wirklich in JDK 7 integriert sein werden. Nachdem sich David Flanagan Ende letzter Woche über das Schweigen von Oracle zu dem Thema beklagt und die rechtzeitige Umsetzbarkeit in Frage gestellt hatte, antwortet Goetz nun mit einer offiziellen Stellungnahme, in der er neue Vorschläge für die technologische Lösung des Closure-Problems unterbreitet.

Goetz stellt die Problemlage zunächst folgendermaßen dar:

Habe man ein Java-Interface erst einmal veröffentlicht, sei es unmöglich, neue Methoden hinzuzufügen, ohne damit existierende Implementierungen zu beschädigen. Je länger eine Bibliothek schon veröffentlicht sei, desto wahrscheinlicher sei es, dass insbesondere bei der Einführung von Closures Probleme entstünden.

Doch Closures einzuführen, ohne auch Collection-Klassen so zu erweitern, damit sie von den Vorteilen von Closures profitieren (z.B. Methoden wie forEach, map, filter, reduce), würde von der Community als halbherzig und unzeitgemäß wahrgenommen.

The addition of closures to the Java language in JDK 7 place additional stress on the aging Collection interfaces; to add closures without extending the Collections classes to take better advantage of closures (e.g., methods like forEach, map, filter, reduce, etc) would be seen as anticlimactic by the community. Brian Goetz

Auch statische Erweiterungen könnten aufgrund diverser Limitierungen nicht die Lösung sein:

In general, static-ness is a source of all sorts of problems in Java, so adding more static mechanisms seems like a step in the wrong direction. Brian Goetz

Goetz schlägt zur Lösung des Problems die Einführung des Konzepts der "virtuellen Extension-Methoden" (Public defender methods) vor.

In this document, we propose adding a mechanism for adding new methods to existing interfaces, which could be called virtual extension methods. Existing interfaces could be added to without compromising backward compatibility by adding extension methods to the interface, whose declaration would contain instructions for finding the default implementation in the event that implementers do not provide one. Brian Goetz

Ein Beispiellisting - ein Set-Interface, das um eine virtuelle Extension-Methode erweitert wird - könnte dann wie folgt aussehen:

1. public interface Set<T> extends Collection<T> {
2. public int size();
3. // The rest of the existing Set methods
4. extension T reduce(Reducer<T> r)
5. default Collections.<T>setReducer;
6. }

Ziel der Einführung dieser Public-defender-Methoden sei es, Interfaces flexibler zu halten und für spätere Erweiterungen zu öffnen:

The intent of this feature is to render interfaces more malleable, allowing them to be extended over time by providing new methods so long as a default (which is restricted to using the public interface of the interface being extended) is provided. This addition to the language moves us a step towards interfaces being more like “mixins” or “traits”. However, developers may choose to start using this feature for new interfaces for reasons other than interface evolution. Brian Goetz

Ob diese Änderungen allerdings schon in JDK 7 enthalten sein werden, steht weiterhin in Frage. Goetz selbst erwähnt die Möglichkeit, zunächst Closures einzuführen und die beschriebenen Library-Änderungen in einem späteren Update oder in SE8 nachzuholen.

Ein PDF des Vorschlags steht hier zum Download bereit. Goetz hat indessen ein weiteres Dokument veröffentlicht, in dem er die Überstzung von Lambda-Ausdrücken nach javac beschreibt.