Siehe http://mail.openjdk.java.net/pipermail/lambda-dev/2011-November/004191.html bzw. http://jcp.org/en/jsr/detail?id=335.
Folien zur aktuellen Lambda-Version von der Konferenz sind hier: http://blogs.oracle.com/briangoetz/resource/devoxx-lang-lib-vm-co-evol.pdf.
Der aktuelle Compiler weist aber noch Unterschiede auf, sie werden hier diskutiert: http://mail.openjdk.java.net/pipermail/lambda-dev/2011-November/004253.html.
Now if you restart Felix (via Knapsack if you are running a 3.0 release), you’ll notice that the JVM running is java.runtime.version = 1.7.0_147-icedtea-b147 via http://bug/support.html. This is provided on an experimental basis and I would not be surprised if problems pop up!
Das sie die „neuen“ Methoden beim Iterator einfügen wollen ist echt Mist.
Beispielsweise benutze ich dieses Interface bei einigen Klassen selbst und in diesen Klassen habe ich dann recht ähnliche Methoden, aber die andere Parameter Typen und/oder Return Typen haben. Da kann ich mich jetzt schon freuen, wenn ich das für Java8 alles umbiegen muss. 🙁
Schöne Übersicht über den aktuellen Stand der Entwicklungen. Als API designer gefallen mir besonders die „Virtual Extension Methods“. Damit wird es wirklich viel einfacher, eine API über Jahre hinweg weiterzuentwickeln.
Ich habe mir dann z.B. noch überlegt, dass diese neuen Extension Methods eigentlich auch „final“ sein könnten. Ich weiss nicht ob Brian Goetz schon daran gedacht hat? Hier ist ein Blog Post zu diesem Thema, sowie eine Anfrage auf der lambda-dev Mailingliste:
– http://lukaseder.wordpress.com/2011/12/18/java-8-virtual-extension-methods/
– http://mail.openjdk.java.net/pipermail/lambda-dev/2011-December/004426.html
Ich würd mich über Support für diesen Vorschlag auf der Mailingliste freuen 🙂