Java 8 ya esta disponible.

Crei que ibamos a tener que esperar otra decada pero no, Java 8 ya esta disponible para descargar

http://www.oracle.com/technetwork/java/javase/downloads/index.html

El lanzamiento oficial será el 25 de marzo. Eso y otros detalles aqui:

http://mreinhold.org/blog/jdk8-ga

Que comienze el Lambdamiento!!

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 Jose Manuel

Pretextos, pretextos que son tan mios.

Chale, dos años y medio no me alcanzaron para aprender y sobre todo comprender las características de Java 7 y ya va a salir el 8... ¿Como le hacen para estar al tiro? Que no duermen o que onda :P

Imagen de echan

poooorfin, aaadios PermGen

poooorfin, aaadios PermGen space exception. No te vamos a extrañar.

Imagen de ezamudio

Migraciones

Recuerdo que cambiar de Java 1.3 a 1.4 fue bastante simple, había algunas mejoras inmediatas en el lenguaje, pero no muchas cosas cambiaron; el java.nio no se me hizo la gran cosa (pudo haber sido útil en algún momento pero pues sigue con broncas).

Cambiar a Java 5 sí fue un cambio más drástico, por la introducción de generics, tipos de retorno covariantes, anotaciones y el java.util.concurrent. Pero bien valió la pena.

El cambio a Java 6 me pareció bastante transparente, honestamente ni siquiera recuerdo cuáles eran las novedades de Java 6, sólo recuerdo que java.util.concurrent tenía algunas mejoras en su implementación pero los APIs no recuerdo que hayan cambiado.

Las mejoras de Java 7 se me hicieron pocas también pero más notorias que las de Java 6: try-with-resources y multicatch, principalmente; aunque para los que ya estábamos usando Groovy (y seguramente Clojure, JRuby, y otros lenguajes dinámicos) la introducción de invokedynamic se tradujo en mejor desempeño en nuestro código existente, simplemente con recompilar usando las libs con sufijo indy (y usarlas en tiempo de ejecución también). Pero igual, fuera de eso, qué más venía? Huy, el "diamond operator" [sarcasmo]WOOOOOOOOOOOOOOOOOOW qué fregonería![/sarcasmo].

Pero ahora para Java 8 pues lo principal son las lambdas. No sé qué más cosas hayan incluido, pero lo que pienso es que simplemente esa nueva característica del lenguaje, es un cambio significativo en la manera de programar Java. Supongo que no nada más puedes usar lambdas en tu código, sino que cambiaron muchas de las APIs existentes (especialmente en colecciones) para que puedas pasar lambdas y hacer los típicos map/reduce/filter en colecciones, lo cual me parece un cambio muy bueno, ya que a partir de que empecemos a usar Java 8 en nuestro código, podremos escribir bastante menos en muchos casos, y eventualmente cambiar APIs existentes para poder usar lambdas también. Los lugares más obvios es donde se tuvieron que programar interfaces de un solo método.

Esto de que ya no hay broncas del PermGen es algo que solamente pasa en tiempo de ejecución, no afecta realmente la forma de programar, pero realmente será un alivio ya no tener ese problema en sistemas en producción.

Todavía no sé cómo será la mejor manera de cambiar a Java 8 para mi, particularmente porque en Ceylon seguimos amarrados a Java 7 y no tiene sentido cambiarnos a Java 8 todavía (el compilador para bytecode depende del javac 7), pero en "mi otra chamba" bien podríamos cambiar a Java 8 en cualquier momento, siempre y cuando funcionen todas las dependencias:

  • Groovy 2 (ya sabemos que sí funciona, esos cuates probaron bastante)
  • Grails (no sé si probaron y qué tal funcione sobre Java 8)
  • Spring (tal vez haya que pasarnos a Spring 4, no sé)

Esas son las principales cosas que nos va a tomar tiempo probar. Lo demás no creo que tenga mucha bronca. Y después de eso pues habrá que ver dónde vale la pena empezar a introducir lambdas, para reemplazar interfaces existentes, simplificar APIs, etc.

Imagen de echan

El caso de los lambdas es el

El caso de los lambdas es el cambio mas radical desde los genericos, pero creo que lo tenian que hacer por cuestiones estrategicas, no por que la programacion funcional sea una moda, si no por que está comprobado que es una solucion adecuada al multicore, multiprocesador, distribucion etc. y simplemente es impractico escribir código concurrente con java.util.concurrent, me atrevería a decir que es mas sencillo hacer funcionar un programa concurrente con algunos conceptos basicos de la programacion funcional en Java 8 que con el framework de concurrencia.

La adopción a lo mejor sea mas con sistemas nuevos, es muy dificil migrar sistemas grandes, sobre todo si hay muchas dependencias de librerias y frameworks de terceros donde no tienes el control.

Imagen de echan

adios java.util.Date. Tampoco

adios java.util.Date. Tampoco te vamos a extrañar. Hail java time !!!