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

Ya que se avivó la discusión en este tema acerca de si los 'Closures' son necesarios o no en Java pongo este tema.

A pesar de las varias propuestas que ha habido mediante JSR para incluír Closures en la JDK7 parecían haber sido todas rechazadas, e incluso algunos intentos por emularlos como este, el tema sigue dando de que hablar.

¿Son los closures realmente necesarios para el lenguaje Java? (expresen su opinión al respecto en un comentario).

El principal problema que yo veo, es el hecho de que Java es un lenguaje imperativo, y el concepto de un closure va más hacia lo funcional, de alguna manera no encaja y en mi opinión al incluírlos se cambiaría de alguna manera la manera de codificar.

El día de hoy se avivó de nuevo el tema, ya que Mark Reinhold (quien apenas hace unos días anunció el Milestone 5 de la JDK7) en su conferencia en Devoxx anunció lo que podría ser la inclusión (aún no confirmada oficialmente) de Closures en la JDK7.

Chequen:

Si esto es cierto el debate se avivará, más por el hecho de que pareciera que todo mundo se había hecho la idea de que no serían incluídos.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

Fashion

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.

Imagen de Nopalin

No son necesarios

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

Imagen de benek

Actualizando

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:

Re: No son necesarios

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

Imagen de luxspes

C? y C++ ? Los closures

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

Imagen de ezamudio

C function pointers

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

Re: C function pointers

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

Saludos

Javier Castañón

Imagen de willyxoft

Closures en Java

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.

Imagen de ezamudio

En contra?

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.

Imagen de benek

Callbacks

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 ni de C++ sino de Scala

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:

Imagen de jlbarros

Closures Vs. Inner Class

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

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

:)

Aportación: Los closures no fueron

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.