La modularidad en el JDK y el código espagueti de las librerías estándar Java

Con práctica total seguridad, el JRE 7 será un JRE modular, siendo posible instalar sólo un subconjunto de las partes del JRE, e ir instalando el resto de ellas bajo demanda. Será posible construir aplicaciones Java que instalen el JRE a través de la red sin suponer un proceso de descarga e instalación traumático para el usuario, como es en la actualidad, acercándose así a la experiencia de la instalación del plugin de flash.

Idealmente, todo esto ocurrirá de un modo completamente transparente para los programadores. Serán los ingenieros de Sun (o, probablemente, son ya) los que se romperán la cabeza para ver cómo rompen el JRE en módulos. Aunque esto no quiere decir que un programador no pueda tomar ventaja de esto diseñando su aplicación de tal modo que si los usuarios necesitan descargarse el JRE el tamaño de la descarga sea lo menor posible.

Probablemente, al menos para los ingenieros de Sun, ha llegado el momento de pagar el precio por haber hecho tanto código espagueti. Sí, porque las librerías estándar Java son un buen ejemplo de código espagueti. Es complicado encontrar entre ellas un paquete, o conjunto de paquetes, que puedan considerarse un módulo independiente. Idealmente, el paquete java.lang debería ser una especie de paquete "core", que no dependiese de nadie más, y del cual dependería todo el mundo. Sin embargo, este paquete depende de múltiples otros; entre ellos java.util y java.io.
El paquete java.util probablemente debiera ser la siguiente capa sobre java lang, sólo con dependencias con java.lang. Sin embargo, no es así; entre otros, este paquete también depende de java.io. Y java.io depende de java.net y java.security, entre otros...

La crítica de que el código de las librerías estándar no es modular es bastante vieja. La defensa de Sun es conocida: se trata de una base de código con ya bastante edad, donde mantener la compatibilidad hacia atrás es de suprema importancia y otros aspectos (como el buen diseño) se sacrifican para ello; y "no importa que no sea modular, porque Java SE es todo un bloque y no se puede distribuir por partes", así que los beneficios de una buena organización modular del código se verían reducidos. Obviamente, el segundo argumento se cae con Java 7.

Este código espagueti va a hacer que para partir las librerías estándar en módulos en vez de trabajar a nivel de paquete sea necesario bajar a nivel de clase. Desde mi punto de vista, esto sin duda va a complicarle mucho la vida a los ingenieros de Sun que están llevando a cabo la modularización. No tengo tan claro si nos pasará factura a todos los programadores cuando intentemos hacer una aplicación que produzca una descarga mínima para aquellos usuarios que no tengan instalado el JRE. Pero podría hacerlo; simplemente por tocar cierta clase de java.lang (Process) puedo crear una dependencia con java.io (InputStream). Si este InputStream resulta ser una instancia de, por ejemplo, FileInputStream tengo una dependencia también con File. Esta clase del paquete java.io depende de java.net.URI, la cual depende de java.net.URL, la cual depende de java.net.URLConnection, quien acaba produciendo una dependencia con java.security.ProtectionDomain... Aunque no lo he mencionado en el ejemplo, también tendría múltiples dependencias con java.util. Con sólo tocar una clase del supuesto paquete "core" he creado dependencias con la mitad del código de las librerías estándar.

¿Creéis que el hecho de que las librerías estándar Java no estén bien organizadas en módulos independientes va acabar pasando factura ahora que vamos a tener JREs modulares? ¿Serán capaces los ingenieros de Sun de abstraernos de todo este problema?