¿Hay alguna desventaja en el uso de comodines de Java 6 en mi classpath? p.ej.¿Por qué no usaría un comodín en mi classpath?
C:> set CLASSPATH=.\lib\*
puedo ver que donde hay dos frascos que contienen tanto una clase con el mismo camino y luego usando un comodín puede conducir a resultados que son difíciles de localizar.
Pero aparte de eso, ¿hay algo más a tener en cuenta?
Si es lo que quieres hacer, hazlo. Mientras seas consciente de las consecuencias. Tenga en cuenta que si alguien más tiene que mantener el proyecto, pueden copiar un montón de jarras en esa carpeta sin darse cuenta de que estarán vinculadas por defecto. Sin embargo, no debería tomarles demasiado tiempo para ver lo que está sucediendo.
por lo general tratan de minimizar el número de archivos JAR que uso, y vincular a todos en forma manual. Me doy cuenta de que esta es una preferencia personal.
Es posible que usted dando la JVM una gran cantidad de lugares para buscar, esto podría dar algo de sobrecarga como clases se cargan - supongo que una JVM inteligente va a hacer esto de manera eficiente.
Es posible cargar las clases no deseados, al hacerlo, y si hay dos versiones de la misma biblioteca; bueno, kaboom
Una ruta de clase explícita puede servidor como una documentación de lo que las bibliotecas (y tal vez lo versiones de los mismos!) La aplicación depende.
Se pierde esto si usa comodines: si no está documentado en otro lugar, si alguien obtiene una copia de la aplicación sin la carpeta lib (o la elimina accidentalmente), tendrá un tiempo muy difícil para rastrear todos las dependencias mediante la ejecución repetida de la aplicación, mirando a ClassNotFoundError sy esperando que todas las bibliotecas usen nombres de paquete lógicos.
Mi primera reacción fue no utilice env.CLASSPATH, pero pensándolo bien y pensando en por qué uno no debe hacerlo empecé likeing la idea, al menos por un desarrollo local y entorno de prueba (y por lo menos por un tiempo)
el ventaja de este enfoque es que se puede mantener a una carpeta local con todas sus bibliotecas comunes (log4j, dom4j, tiempo de joda, colecciones de Google, el apache commons zoológico, .. .). De modo que puede compilar y ejecutar todas sus aplicaciones desde el shell sin perder tiempo escribiendo argumentos largos de classpath.
Y su aún libre usar un argumento -cp, porque reemplaza la configuración global CLASSPATH.
Nunca lo usaría en un sistema de producción. El riesgo es tan alto que alguien cambia el contenido de esa carpeta o la variable CLASSPATH y mi aplicación ya no funciona.
Así que para la producción, no 'CLASSPATH' global y no hay comodines en la cadena de ruta de clases.
desventaja de utilizar la ruta del comodín en un entorno como el anterior: después de un tiempo, demasiados proyectos dependen de la carpeta de la biblioteca individual. No conoce los efectos secundarios de actualizar una biblioteca o eliminar una anterior. Y para aplicaciones grandes, puede ser difícil averiguar qué bibliotecas de la agrupación realmente se necesitan.Puede terminar agregando librerías no utilizadas al producto solo porque no está seguro si la aplicación se ejecutará sin esa lib.
Así que mi conclusión: un buen atajo para el desarrollo, las pruebas, la creación de prototipos pero arriesgado para la producción. Para producción preferiría cadenas de clase (autogeneradas) sin comodines.
No estaba preguntando sobre $ CLASSPATH vs -cp. Nunca usaría $ CLASSPATH en un entorno de producción. Estaba tratando de hacer la pregunta lo más clara que pude. –
Sé que la pregunta era sobre el comodín solamente, la respuesta es algo así como * extended *;) –
fwiw, mi carpeta lib es regenerada por mi compilación maven de mis dependencias utilizando el complemento appassembler como parte de la fase de empaquetado. Mi POM es el documento final para definir el classpath. –