¿Closures en Java? ... aún podrían incluirse en la JDK7

Si los closures en Java fueran necesarios, los hubieran metido en la versión 2, no en la 7.

Creo que más bien los van a meter para no quedarse atrás, pero pues no creo que sean realmente necesarios, pero pues la siguiente vez que necesite usarlos (quién sabe cuándo será), ya podré usar algo así.

Es como con JavaFX, que solamente existe para que no digan que Java se queda atrás y es el contrincante de Flash (como Silverlight de MS) pero no es un proyecto realmente significativo, no ha tenido gran adopción.

Por el momento me imagino que proyectos como Hadoop se pueden beneficiar de closures en Java, y una que otra cosa de Spring (pueden simplificar el uso de varios templates, usando closures en vez de callbacks) pero es algo que cambie por completo la manera de programar en Java, como fue el caso con generics y sobre todo con las anotaciones.

En realidad yo creo que los closures los piden gente que está acostumbrada a trabajar con c/c++, pero en nada ayudan a la programación en java, si somos objetivos cual sería la única ventaja de los closures? poder ejecutar inyectar código en runtime? eso a mi como que me da la impresión que se preste a un java inyection jeje.

sobres

Actualizando, Joseph D. Darcy confirmó ya que los closures vendrán en la JDK7, aunque serán una especie de lightweight closures:

En InfoQ lo explican muy bien:

La gente acostumbrada a trabajar con C++ generalmente no usa closures pues si mal no recuerdo dicho lenguaje no los soporta. :-O

Bueno, en realidad hay librerías de C++ que por medio de templates simulan la funcionalidad. Además, es más común encontrarlas bajo el nombre de lambda functions. Y no, la intención de los closures no es inyectar código en runtime.

Saludos

Javier Castañón

C? y C++ ? Los closures vienen de la programacion funcional, no de C, lo mas probable es que los hayas usado si alguna ves programaste Lisp. Aunque mas modernamente son soportados en C#, Ruby, Scala, Delphi, Clojure... en este sentido Java estaba quedandose atras... aunque por otro lado, las ideas que visto sobre como le quieren adaptar esta nueva caracteristica a Java no me convencen mucho... siento que esto podria terminar por convertir a Java en una "olla de mondongo". En mi opinion lo que deberia de hacerse es trancisionar poco a poca hacia un lenguage mas moderno como Scala

En C puedes pasar apuntadores a funciones como parametros a otras funciones. Es el equivalente primitivo de closures.

Pero no el mantenimiento automático del contexto (estado), que es una (o la) característica relevante de un closure.

Saludos

Javier Castañón

Pues en mi caso celebro que se incluyan. No creo que signifiquen una carga al lenguaje como para no hacerlo, por lo que no veo porqué el disgusto de algunos por incluirlos. O si estoy errado por favor corríjanme ¿Que consecuencias negativas reales y concretas traería el incluirlos?
Ahora bien, también es cierto que no son algo con lo que no se pueda vivir. Pero si existe la opción de usarlos, pues en los escenarios donde resulten útiles los usaremos, cuando no, pues ni quien se acuerde de ellos.

Creo que nadie expresó disgusto por los closures. No sabría decirte si vaya a tener consecuencias negativas el incluirlos en el lenguaje, fuera de la complejidad de la nueva JVM o del compilador; quiero confiar en que serán cuidadosos de que no se afecte el performance de aplicaciones que NO utilizan closures.

En mi caso la protesta era solamente de que mucha gente ahora se pone a brincar de gusto porque Java incluye closures, como si fuera algo sin lo cual no podían ni siquiera hacer un HelloWorld. O como si fueran lo más necesario del mundo. Ciertamente pueden ser útiles en algunos casos, pero no es como para decir que ya la industria del software por fin podrá salir del abismo en que se encuentra porque Java va a tener closures.

Lo que me temo que va a pasar con los closures es que se van a empezar a utilizar como las anotaciones. Las anotaciones tienen su uso y aplicaciones, pero de repente pareciera que hay quienes las quieren utilizar para absolutamente todo. De igual manera es probable que cuando Java tenga closures, empecemos a ver que muchos frameworks los adoptan; habrá algunos buenos usos pero seguramente vamos a encontrarnos con casos donde metieron closures simplemente porque se podía, aunque no sea la mejor solución.

Pero pues eso sucede con cualquier cosa nueva.

Ya no recordaba que uno de mis primeros posts en la comunidad fue precisamente sobre un Callback, quizá me salgo un poco de la temática inicial pero por si alguien lo quiere revisar:

Javier Ramírez Jr.

Las closures no provienen de C/C++ sino de lenguajes funcionales como Haskell, en particular para java seria Scala amigo. Ademas lo ideal seria que las closures SI sean usadas extensamente y de hecho lo van a ser, para que pueda desarrollarse aplicaciones mediante programación funcional, en vez de imperativa en java, los procedimientos (funciones que no devuelven ningun valor), y otras maneras de programar como el uso del while son, estilos de programación imperativos, que pueden evitarse del todo utilizando por ejemplo closures, lo cual evitaría efectos de borde (side efect o efecto colateral), un efecto de borde es el cambio de estado de una variable, esto ocurre en clases mutables y programacion imperativa, la programación funcional se logra mediante el uso de clases inmutables y closures, lo cual hace que la depuración sea mucho mas sencilla cuando empleas programación funcional, ademas al emplear el paradigma de programación funcional no solo evitas los efectos de borde sino también los problemas de concurrencia, es algo asi como que si usas programación funcional tu aplicación quedaría threadsafe. Esto lo hereda java de un interesante lenguaje llamado Scala, te invito a que lo conozcas, y si te gusta mas que java depronto te mudes del todo a Scala:

Si mal no recuerdo, James Gosling escribió un post en su blog donde decía que los closures en Java no se implementaron tempranamente, más que todo debido a premuras de tiempo. La salida fácil fue crear las clases internas. Pero como él mismo dice, las simplificaciones no resuelven los problemas, sólo los mueven a otro sitio. Los closures eran una deuda que Java estaba tardando en pagar. En mi concepto, las clases internas resultan mucho menos poderosas y requieren más código.

Los closures pueden reemplazar a las clases internas con una estructura de programación más poderosa y flexible. Ahora bien, si te siguen gustando más las clases internas, las puedes seguir usando.

Los closures no fueron introducidos en Java originalmente porque el paradigma no lo soportaba y el mercado no estaba listo entonces. Las clases anónimas internas son el exacto equivalente, que la sintáxis sea muy engorrosa es otro tema.

Es un error pensar que por usar closures ya no se tienen efectos colaterales o que no se tienen problemas de concurrencia:

Haskell es relativamente nuevo ( 1990 ) la programación funcional precede incluso a la programación estructurada ( ya no digamos a la Orientada a Objetos ) y ... bueno ya.

El caso es que los closures vedrán en Java 8

:)

Algo que de verdad me ha llamado la atención es:

Es un error pensar que por usar closures ya no se tienen efectos colaterales o que no se tienen problemas de concurrencia

Pues no sé, pero el paralelismo no tiene mucho que ver con los closures
incluso en JavaScript puedes hacer que cuando pases un closure se ejecute
al más puro estilo de un ciclo (de uno en uno) aunque más bonito de sintáctica.

Lo de concurrencia, pues, no sé de verdad que en Groovy y Ruby, al pasar un
closure tengo entenido se bloquea hasta que se termina de ejecutar. Un ejemplo
sencillo:
 
Es completamente lineal, se ejecuta paso a paso y hasta que no se termina
de ejecutar el closure se sigue la ejecución.

Que comentario tan más acertado, y como bien comentas la programación
funcional viene desde antes...si incluimos a las mates en este tema, creo que
tienes toda la razón, aunque ¿las mates lineales se consideran más funcionales
y no tanto imperativas?...o puede que sí ya que entran parámetros y salen resultados
no más no menos.