Javaone2010: Comentarios sobre J2SE{7,8}, OpenJDK...

Recién llegado del Appreciation Event (donde, entre otros, han actuado los Black Eyed Peas -espectacular Bom, Bom, Pow-), lo primero que se me ocurre es... ¡contar algunas impresiones de las últimas sesiones! Estoy convencido de que alguna de las cervezas consumidas contribuye a esta extraña decisión ;)

J2SE: ya sabéis por dónde van los tiros: J2SE7 para 2011 (mediados) y J2SE8 para finales del año siguiente. J2SE es una versión evolutiva, pero que incorpora muchos cambios para hacer más fácil la vida al programador.

Del proyecto Coin (J2SE7) es curioso cómo el operador "diamante" (aka "<>", que nos permite obviar el tipo -de una clase genérica- en el RHS de una asignación cuando ya está parametrizado el del LHS) ha sido de los más complicados de implementar. Al parecer, el algoritmo de inferencia de tipos (target typing) es todo menos trivial, y ha sido determinado ¡experimentalmente! Habrá algunos casos puntuales donde se limite la inferencia de tipos, porque el actual algoritmo no cubre el 100% de los casos. Otras mejoras son los nuevos literales, absolutamente fantásticos (expresar un número como 100_000_000_000 o en bin/hex/oct con igual facilidad), o el catch múltiple (por fin no más c&p -yo no lo hago- en los catch).

Me gusta el try-with-resources, que permite autogestionar la liberación de recursos que implementen el interfaz AutoCloseable (que en las librerías implementarán I/O, Sockets y JDBC, IIRC), de forma que sea trivial escribir código sin fallos (como ejercicio para el lector, invito a que alguien postee un código *correcto* para copiar un fichero; aviso: no es nada sencillo escribir un código absolutamente correcto, invitados estáis a postearlos). Echo en falta, sin embargo, y por lo que pregunté expresamente, un mejor soporte de enums, como por ejemplo herencia y composición que sea sencilla de hacer. La respuesta fue que no hay planes, pero que lo plantee en las listas correspondientes. OK, habrá que pensar en ello.

Ya en el mundo J2SE8, destaca para mí Jigsaw, la modularización en el mundo Java. La eliminación del classpath y la gestión de dependencias. Aquí, pocas novedades con respecto a lo que ya sabíamos y se contó en la JavaOne del año pasado, con la excepción del soporte de repos mvn como repositorios de "módulos" java para resolver las dependencias de un programa. Sin embargo, me sorprendió que hubiera poca (ninguna) información (y también pregunté por ello, aunque las respuestas fueron vagas) sobre la modularización de la propia JVM (me corrijo: del JRE): qué módulos va a tener, cuánto van a pesar y, en esencia, en cuánto se va a aligerar la JVM. Quiero saber si finalmente para cosas que no usen GUI, ni sonido, ni CORBA podemos tener un JRE ligero, de arranque muy rápido y que sea razonable de embeber, si se precisa. Pero habrá que esperar para saberlo. Curioso también que los módulos de java van a ser limitados con respecto a otros sistemas de paquetes, y aún debaten si va a existir un módulo virtual: aquél que no provee una funcionalidad directamente, sino que otros paquetes la proveerán; esto entronca mucho con paquetes de sólo interfaces, pero es algo que aún no está precisado.

También para J2SE8 se encamina el proyecto lambda. A mí me parece espectacular. No por la sintaxis en sí (que me da más o menos igual), sino por el concepto bajo el cual lo han vestido: máxima concurrencia y aprovechamiento de los recursos (cores, CPUs) por el hecho de internalizar las operaciones sobre colecciones (no se hacen en bucles for, sino mediante métodos como filter o map), de forma que la implementación determina cómo hacerlo, y puede fácilmente paralelizarse sobre todos los cores de la máquina. Ello, junto con las famosas lambdas y la inferencia de tipos, van a permitir mucha potencia con poca sintaxis.

Ahora bien, para realizar estas nuevas operaciones sobre colecciones, se requieren ampliar los actuales interfaces de Collection pero... ¡esto no se debe hacer! ¡Romperían todo el código actual! Se van a introducir un concepto en los interfaces que son los métodos por defecto, que si no se implementan, el interfaz define a qué método estático de una clase llama. La solución parece muy elegante e interesante, incluso para nuestro propio uso, pero reabre un viejo e interesante debate, la herencia múltiple. ¿Qué sucederá, entonces, si dos interfaces definen un mismo método por defecto? La respuesta, todavía no está lista...

Más. Sobre OpenJDK. Estuve en el BOF y pregunté algo que muchos seguro os preguntáis: pero entonces, ¿es ya usable OpenJDK? ¿Es mejor o peor que el de Sun (perdón, Oracle)? ¿Está listo para producción? La respuesta (resumida, la real fueron casi 5 minutos) es muy simple: Oracle JDK es 98% OpenJDK, y el 2% restante son cosas que muy raramente se usan. Así que podemos hacer ya s/Oracle JDK/OpenJDK/. La única diferencia es que OpenJDK requiere para muchas distros IcedTea para hacer el bootstrapping de la compilación, pero eso es todo. Interesante, por otra parte, que OpenJDK va a ir recibiendo contribuciones de JRockit, y poco a poco se va ir portando código para soportar Mission Control.

Poco más, seguiremos informando desde este gélido SFO (sí hace fresquito...)