Interfaces funcionales en Java 8

Es algo bastante útil. Espero que le metan ahora sí algunos métodos útiles a las colecciones, como map/fold/filter, para poderlas usar como en Groovy, Scala y Ceylon.

Según también se podrá incrustar código Javascript dentro de aplicaciones Java y viceversa y otras cosas más (antes decían que iban a quitar Swing).

Parace que la libreria estandar en especial las colecciones van a tener su "overhaul"

Osea que pudiera implementarse así tambien:

Desde mi persepcion, los closures son una moda medianamente util, que en su mayoria solo es sintactic sugar, que quien abuse de ellos en java convertira el codigo no muy facil de leer como lo es actualmente, o si alguien me pudiera explicar por que nos beneficiamos podria compartir su emoción.

Saludos

Nopalin, como bien dices, puede usarse sólo como azúcar sintáctica para ahorrarse algunas líneas en ciertos casos. No sé si en Java se van a poder definir inline, lo cual te puede ahorrar aún más código, sin que quede completamente ilegible. En vez de definir un traductor y reutilizarlo, como en el ejemplo original, podrías definir un traductor para cada caso, cuando alguien espera recibir un objeto de ese tipo. Eso es bastante más legible que definir una clase anónima inline, creo yo:

En Groovy puedes hacer cosas similares; cuando tienes un método o closure lo puedes "castear" a una interfaz de un solo método para evitarte crear una clase anónima (Groovy la va a crear por ti). Esto es muy útil para cosas como los ActionListeners de Swing/AWT o algunos otros callbacks o notificaciones:

En Ceylon no puedes hacer ese casting pero no es necesario porque en Ceylon puedes definir métodos que reciban una función como parámetro, y les puedes pasar cualquier función que tenga la firma correspondiente, o bien definir una función anónima:

Cuando trabajas con colecciones esto se vuelve muy útil porque generalmente quieres aplicar una transformación o hacer una búsqueda muy simple y no tiene caso definir una función que solamente vas a usar una vez, es más rápido crearla ahí mismo:

En eso si tienes toda la razón, java es tan verboso que muchas veces terminas haciendo clases de utilerias para muchas por el simple echo de que estarlo definiendo por cualquier lado se vuelve tedioso. Utilize groovy y la creacion de mapas con metodos y castearlo a una instefaz es fabulosa, ahorra tener que andar definiendo inner clases a cada rato, y sobre todo para swingcomo bien mencionas, que los action, key y mouse listeners estan a la orden del dia.

Pero aun asi sigo sin ver/apreciar realmente el potencial de los closures, si me queda claro que me ahorraria mucho algo de tiempo al trabajar con colecciones, pero por el momento no veo otro alcance mas allá. Por decir algo, en java actualmente puedo definir metodos static con algo en particular a realizar, si eso lo implemento cada vez que ese algo lo ocupe mas de 1 vez, donde quedarian los closures? tendria que seguir creando closures que a la larga seria mas batalloso que crear un metodo static?

ademas de lo sintactico los closures son una apuesta a un mejor modelo de programacion multicore. A estas alturas la ley de Moore no aplica, es decir, los programas no son mas rapidos porque los procesadores son rapidos sino porque se pueden ejecutar concurrentemente. La clave esta en que los closures acercan a java al paradigma funcional y con ello a manejar mejor el estado compartido de un programa. Al evitar la mutacion de variables es facil dividir el codigo en unidades de ejecucion y separarlos en varios hilos y por lo tanto en varios cores.

Buenas compañero perdón por desviarme del tema principal, ¿no sabrás donde puedo encontrar información sobre lo que acabas de mencionar? O sea, como el tipo de paradigma afecta al desempeño y porque la ejecución concurrente es mejor. Yo he buscado información pero, me entro la duda de si tu posees algo mejor o mas completo, alguna referencia a algún libro o revista. Gracias y saludos.

No necesariamente, es decir, el paradigma de programación utilizado no está directamente relacionado con el desempeño de un programa (aunque sí a menudo con el de los programadores :P) y el asunto de la concurrencia no es algo que sea en si mismo bueno o malo. Con cualquier paradigma puedes tener un desempeño desastroso utilizando un algoritmo inadecuado. La concurrencia es una situación que debemos saber manejar si queremos resolver optimamente los problemas de programación en un entorno multi-core y cada vez mas interconectado simultáneamente.

Algunas ligas clarificando estos puntos:

• The Structure and Interpretation of Computer Programs:
• Out of the Tar Pit:
• Are we there yet?:
• Functional Programming Basics:

Saludos

coincido con alcides, ni el paradigma funcional ni la concurrencia son mejores per se, son mas convenientes cuando necesitas escalar a cientos o miles de usuarios conectados a tu software. Hacerlo con el modelo dominante en Java es arto dificil, porque se basa en la mutacion de valores compartidos dentro de un entorno multithreading, y con eso deadlocks, retenciones, condiciones de competencia, etc, etc. y asi es muy probable que termines con una ejecucion no determinista .

Aqui van otros enlaces que explican mejor lo que quiero decir:

Perfecto, gracias por las aclaraciones y por los enlaces. Tratare de darle un buen uso al material de apoyo que me brindaron.
Saludos.