Cierres en Java 7

Question

Entonces, ¿Java 7 finalmente va a obtener los cierres? ¿Cuáles son las últimas noticias?

Answer 1

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

Answer 2

Las últimas noticias es que yo sepa todavía que a finales de noviembre de 2009, que los cierres serán en Java 7 en alguna forma. Dado que esto se dio como la razón principal de un retraso significativo en el lanzamiento, parece bastante improbable que lo abandonen de nuevo.

Answer 3

Sí, los cierres se incluyeron para liberar el plan de java 7 (y fue la razón más importante para retrasar el lanzamiento de invierno a otoño (se espera en septiembre de 2010)).

Las últimas noticias se pueden encontrar en Project Lambda. También te puede interesar leer latest specification draft.

Answer 4

Ha habido una gran cantidad de debate relacionado con la sintaxis y la transparencia (particularmente centrándose en qué tan difícil es leer una función de currificación con una sintaxis particular, parece) en la lista de correo de lambda-dev, y ha habido un par de versiones preliminares de propuestas de Sun, pero hace mucho tiempo que no veo mucho de ellas en esa lista.

Answer 5

No hay declaración oficial sobre el estado de los cierres en este momento.

Aquí están some readable examples de cómo podría funcionar y verse.

Si desea obtener información sobre lo que está pasando, lo remito al OpenJDK mailing list.

general

Básicamente hay alguna esperanza, porque el código junto con algunas pruebas ya se ha comprometido a alguna rama código fuente y hay al menos algo de infraestructura a medio camino de trabajo para probarlo.

el mensaje de cambio de Maurizio Cimadamore lee:

impulso inicial lambda; El prototipo actual suuports las siguientes características:

• tipos de función sintaxis (opcionalmente habilitados con -XDallowFunctionTypes)
• tipos de función subtipificación
• soporte completo para la expresión lambda de tipo 1 y 2
• inferencia de tipos lanzados/tipo devuelto en una lambda
• conversión lambda utilizando las reglas especificadas en el borrador v0.1.5
• referencias de soporte a 'esto' (tanto explícita como implícita)
• traducción usando el método maneja

La Creación de un script modificado del repositorio langtools ahora genera un jarfile adicional llamado javacrt.jar que contiene una clase auxiliar que es utilizada durante la conversión SAM; después de la acumulación, la generada guiones javac/java se hará cargo de configurar automáticamente las dependencias requeridas modo que el código contiene expresiones lambda puede ser compilado y ejecutado .

Pero esto es un trabajo en curso y bastante problemático en este momento. Por ejemplo, el compilador a veces se cuelga en expresiones válidas, no compila el código de sintaxis de cierre correcto o genera código de bytes ilegales.

En el lado negativo hay some statements de Neal Gafter:

Ha sido casi tres meses desde que el proyecto de 0,15, y ahora es menos de dos semanas antes de la TL (herramientas y lenguajes) integración final anterior función de openjdk7 completa. Si ha progresado en la especificación e implementación de , apreciaríamos mucho que sea compartida con nosotros. Si no, quizás podamos ayudar. Si Oracle ha decidido que esta característica ya no es importante para JDK7, también sería bueno saber . Lo que sea que esté sucediendo, el silencio envía el mensaje equivocado.

Un discussion entre Neal Gafter y Jonathan Gibbons:

genial para ver esto, Maurizio! Desafortunadamente llega una semana demasiado tarde, y en el repositorio incorrecto, para ser incluido en jdk7.

Observé que ninguna de las pruebas muestra una variable del tipo de función siendo convertido a un tipo SAM. ¿Cuáles son los planes allí? Jonathan Gibbons response: Desde la lista de características publicado por JDK7 y el calendario publicado por JDK7 parecería estar en contradicción, ¿por qué siempre asume el horario es la correcta? Neal Gafter's answer: Porque recuerdo repetidas discusiones sobre el efecto de que la función establecida se ajustaría en función de su estado de finalización con respecto a la programación .

Algunas personas incluso cuestionan si todo esto tiene sentido ya y suggest moving to another language:

uno comienza a preguntarse, por qué no acaba de pasar a Scala - hay mucho más que necesita ser añadido a Java para construir una combinación coherente de características alrededor de lambdas. Y ahora estas demoras, que afectan no solo a los usuarios de de ParallelArray, sino a todos los que quieran construir software de prueba cuidadosamente reconstruido, en Java.

Parece que nadie está proponiendo agregar una varianza en el sitio de declaración en Java => significa que las interfaces FunctionN<T, ...> no subtipificarán como deberían. Tampoco hay especialización para primitivos. (@specialized de Scala es roto para todos, pero las clases de juguete, pero al menos se está moviendo en la derecha dirección)

No reconocimiento de nivel JVM que un objeto es un cierre, y por lo tanto puede ser eliminado, ya que puede estar con la eliminación de cierre de Scala (si el HOF puede también estar en línea.) La JVM parece agregar algo como una máquina inevitable acceso de palabra a cada sitio de llamada polimórfica, incluso si supuestamente son en línea y no megamórficos, incluso dentro un bucle. El resultado que he visto es aproximadamente una disminución de 2x en microrbenchmarks de juguete como "sumar un array de enteros" si se implementa con cualquier forma de cierres que no sea algo que se puede @linear en Scala. (E incluso en Scala, la mayoría de los HOF son virtuales , por lo tanto, no pueden incluirse.) Por mi parte, me gustaría ver que se puede usar en un lenguaje que fomenta el uso de cierres en cada ciclo for.

Conclusión

esto es sólo un vistazo rápido a todo el problema pasando y las citas y declaraciones no son exhaustivas en absoluto. Por el momento, las personas todavía están en el estado de "¿Pueden los cierres realmente hacerse en Java y, en caso afirmativo, cómo debería hacerse y cómo podría verse?".

No hay un simple "OK, simplemente agregamos cierres a Java durante el fin de semana". Debido a la interacción de algunos errores de diseño como varargs como matrices, tipo borrado ... hay casos que simplemente no pueden funcionar. Encontrar todos estos pequeños problemas y decidir si son reparables es bastante difícil.

Al final, puede haber algunas sorpresas. no estoy seguro de cuál será la sorpresa, pero supongo que será o bien:

• Los cierres no entrará en Java 7 o
• cierres en Java 7 será lo que los genéricos eran en Java 5 (Buggy, cosas complejas, que parece que podría funcionar, pero se rompe tan pronto a medida que empujar las cosas un poco más)

opinión personal

que me pasa a Scala hace mucho tiempo. Mientras Oracle no haga cosas estúpidas con la JVM, ya no me importa. En el proceso evolutivo del lenguaje Java se cometieron errores, en parte debido a la compatibilidad con versiones anteriores. Esto creó una carga adicional con cada nuevo cambio que las personas intentaron hacer.

Básicamente: Java funciona, pero ya no habrá evolución del lenguaje. Cada cambio que las personas hacen aumenta el costo de hacer el siguiente cambio, haciendo que los cambios en el futuro sean cada vez más improbables. No creo que haya ningún cambio en el lenguaje Java después de Java 7, aparte de algunas pequeñas mejoras de sintaxis como Project Coin.

Answer 6

Estoy en una conferencia de lanzamiento ahora y el orador dice que los cierres están llegando a Java 8.