A raíz de un artículo de O'Reilly aparecido en LWN que comentaba los contenidos de un libro de Chris Adamson (Java Network Programming 3rd Edition), he seguido un enlace hacia un artículo suyo de hace ya varios años (fecha del 2002) que me pareció curioso. Como el mismo título del post, el autor propone 10 razones por las cuales cree necesario hacer una nueva versión de Java con las pertinentes modificaciones:

1. Eliminar todos los métodos considerados 'deprecated', campos, clases y interfaces. No me parece una buena idea teniendo presente el gran interés de Java en ser compatible hacia atrás (del inglés, backwards compatibility). Si bien hacer una refactorización con un IDE como Eclipse podría ser una tarea relativamente rápida para paliar esta situación, requiere tiempo, un recurso algo escaso hoy en día.
2. Arreglar las convenciones de nombres. Según el autor, se siguen conservando y arrastrando inconsistencias en la convención de escritura de código Java desde la versión 1.0. Esto supone de nuevo romper aplicaciones que llevan cierto tiempo en producción, por muy lógicas que sean las razones que se vierten.
3. Eliminar tipos de datos primitivos (para que pasen a ser puramente Objetos, como todo en Java). Las ventajas serían el ahorro de uso de wrappers y la mayor consistencia del lenguaje. Los inconvenientes, el mayor consumo de memoria, si cabe, de las aplicaciones basadas en Java, mayor lentitud de proceso, y rotura de la 'backwards compatibility'. Para salvar los dos primeros inconvenientes planteados, el autor propone que sea el compilador el encargado de determinar qué tipo de objeto usar cuando se encuentra un tipo primitivo en el código fuente en función de las necesidades, y mapearlo al Objeto correspondiente (p.ej. si hacemos una suma simple de dos números pequeños, con mapear los respectivos int's a Integers basta).
4. Extender los 'chars' a 4 bytes. Esto es para poder soportar (sin feos workarounds, como hace actualmente el lenguaje usando pares de 'chars' cuando es necesario) caracteres Unicode en el citado tipo primitivo.
5. Arreglar los threads. Según el autor, los grupos de threads no son funcionales, deben eliminarse algunos métodos 'deprecated' por ser peligroso su uso o no estar implementados, y hacer los 'double' y los 'long' atómicos (o bien hacerlos Objetos).
6. Convertir formatos de fichero a XML. Las API's actuales ya tienen sus ficheros (de configuración de Servlets, de construcción de Ant, etc...) en XML, pero no es así con las API's viejas previas a la aparición de este formato (los manifiestos de los JAR's, los ficheros de Propiedades y los Objetos serializados).
7. Zanjar el tema de AWT. Pues ya existe Swing como API actual para diseñar GUI's. Esto no supone eliminar AWT, pues tiene clases imprescindibles para Swing. Sin embargo, contiene clases que mejora Swing, que están para dar soporte, como siempre, al 'legacy source code'.
8. Racionalizar las colecciones. En el actual modelo de Collections hay colecciones de diferentes épocas mezcladas con otras de nuevas, resultando en un pupurri de distintas implementaciones; unas son thread-safe, otras no, algunas devuelven null, otras tiran excepciones, etc... El autor propone el rediseño de las colecciones, o bien eliminar las obsoletas (Vector y HashTable) cuyas funciones estan mejoradas y ampliadas por otras Clases (ArrayList y HashMap).
9. Rediseño de E/S. Existen problemas en el diseño de las Clases de E/S, pues están pensadas desde un punto de vista de programador Unix (hay fallos de diseño orientado a Windows y Mac). Cualquier intento de rediseñar un API para tratar los sistemas de ficheros debía pasar por mantener la compatibilidad hacia atrás, lo cual plantea la necesidad de un rediseño de la API I/O, por ejemplo:
   • La clase File necesita representar un fichero propiamente.
   • La clase PrintStream es desastrosa, debiendo ser borrada y cabiendo usar System.out y System.err como PrintWriters.
   • Los métodos readUTF() y writeUTF() de las Clases DataInputStream y DataOutputStream deben ser, al menos, renombrados, pues no soportan en realidad UTF-8 al 100%.
   • Las Clases Reader y Writer necesitan un método para ayudar a determinar qué carácteres pueden ser usados para almacenar texto.
   • Los juegos de caracteres deben tener el nombre en conformidad con los de la IANA (para basarse en un estándard).
   • El proceso de hacer buffering de las Clases de E/S debería ser automático y estar establecido por defecto.
10. Rediseñar la carga de Clases desde cero, esta vez teniendo en cuenta los factores de la 'human interface'. En otras palabras, encontrar otro método al conocido Classpath, o hacerlo lo menos engorroso posible para el programador.

Finalmente, el autor recalca que hasta la fecha (la del artículo!) Sun hizo caso omiso de sus sugerencias, si bien desconozco si la última versión de Java (la 1.5, aka 5) incorpora alguno de estos cambios. Es por ello que os invito a leer las nuevas características de J2SE 5.0, así como un log de un chat con preguntas de éstas.

Y e aquí el dilema: ¿es mejor dejar estas cosas como están, o cambiarlas siempre y cuando se pueda conservar la compatibilidad con antiguas aplicaciones? ¿O bien es la hora del cambio, dejando el soporte para el legacy de mano de JVM's y JSDK's antiguos -o incluso eliminándolo!-? El debate sigue abierto.