2011-01-29 10 views
5

Parece que todos los proyectos de Java en los que me uno o empiezo siempre tienen commons-lang como dependencia, y por una buena razón. commons-lang tiene toneladas de clases y métodos de utilidad que son bastante estándar, justo con la mayoría de las API estándar en otros idiomas. ¿Por qué Sun/Oracle/JCP no ha adoptado algunas de las cosas en commons-lang en la API estándar?¿Por qué no es commons-lang en la API estándar de Java?

+5

Estoy bastante seguro * algunos * de commons-lang han llegado a Java 7. –

+4

Veo que no usa genéricos, ¿qué pasa con el uso de guayaba en su lugar? – maaartinus

+0

en realidad, parte de la intención del proyecto de guayaba debía incluirse en jdk 7. no sé si eso será realidad o no. – jtahlborn

Respuesta

5

Como ya se señaló, algunas características de la API de commons se han convertido en Java, a menudo implementadas (en mi humilde opinión) mejor de lo que originalmente eran en la biblioteca de commons. Enums es el ejemplo clásico.

En términos de por qué no adoptan más commons-lang, bueno con algunas clases existe el elemento de confusión. Tome StrBuilder por ejemplo, es más poderoso que Java StringBuilder y es extensible. Pero no estoy seguro de que sea para agregar una clase de este tipo en la API central de Java, StringBuilder/StringBuffer son perfectamente lo suficientemente buenos para la mayoría de los propósitos y tener otro allí realmente sería un poco confuso. Realmente no podrían alterar StringBuilder de una manera que acomodaría todos los cambios porque eso podría romper el código existente. Incluso si agregaron uno, ¿qué pasa cuando alguien más viene con otra versión más poderosa? StrBuilder2? En poco tiempo todo es un gran desastre (algunos argumentan que el núcleo API ya está, y mucho menos con tales adiciones.)

Y como siempre con estas cosas, el gran punto es qué se debe incluir en commons-lang. Algunas personas probablemente quieran ver las clases de MutableXXX agregadas, otras las clases de XXXUtils, otras el paquete de tiempo ... no existe realmente un consenso común.

La otra gran cosa es que los desarrolladores de Java tienen que ser mucho más cuidadosos en la API Java central que los desarrolladores de Apache en commons-lang. Si un diseño repugnante en commons-lang es reemplazado en una versión futura, el anterior puede ser desaprobado y eliminado posteriormente (de hecho, esto parece ser lo que sucede). En la API central de Java debe mantenerse por razones de compatibilidad hacia atrás, solo causando más desorden.

Por lo que vale, creo que probablemente se deba incluir más funcionalidad en commons-lang. Puedo ver las razones, al menos en parte, por las que no lo es.

1

Históricamente, Apache Commons implementó algunas de las características que luego se introdujeron en Java 5, como enumeraciones y anotaciones. Su implementación fue lo suficientemente diferente para dificultar la integración.

Cuestiones relacionadas