No a las closures para Java (al menos por lo de ahora) Joshua Bloch

Joshua Bloch es en la actualidad el "Chief Java Architect" de Google; durante su paso por Sun Microsystems fue responsable de diseñar, entre otros, el framework de colections y buena parte del paquete java.util. Recientemente ha hecho una presentación Javapolis a la que ha titulado "la controversia de los closures" en la que, resumiendo en una frase, defiende que todavía es muy pronto para plantearse añadir closures a Java ya que hay que estudiar en detalle todas las implicaciones y los pros y los contras.

En la presentación defiende que la propuesta BGGA para crear closures complicaría excesivamente el lenguaje de programación Java y crearía otra fuente de potenciales códigos incomprensibles como es el caso de los wildcards en generics si se abusa de ellos. También defiende que al añadir una característica nueva a un lenguaje de programación la complejidad que va a añadir a ese lenguaje incrementa exponencialmente respecto al número de otras características con las que la nueva característica interacciona. Y las closures interactuarían con prácticamente todo.

Por otro lado, si queremos usar "function types" en Java, es decir, poder tratar un método una función como si fuese una variable más, o poder "pasar un cacho de código" a una librería sin necesidad de implementar una interfaz podemos hacerlo dentro de la plataforma Java empleando el lenguaje Scala.

Bloch defiende que en vez de usar BGGA sería más prudente apostar por la unión de las propuestas CICE+ARM, mucho más conservadoras y con menos poder expresivo pero que añadirían menos complejidad ha lenguaje. La desventaja de estas dos es que en la actualidad sólo son bocetos, mientras que ya existe una implementación casi completa de BGGA realizada por Neal Gafter, principal responsable de Javac cuando trabajaba para Sun e (irónicamente) compañero inseparable de charlas de Bloch hasta que comenzó la polémica de las closures.

Bloch también afirma que se haga lo que se haga debemos esperar varios años todavía y experimentar con los prototipos. Todavía es muy pronto para proponer un JSR.

¿Cuál es vuestra opinión al respecto?