¿Es malo poner tarros externos en el directorio JAVA_HOME/lib/ext?

Question

Tenemos una aplicación que se ejecuta en un entorno JRE. La aplicación utiliza algunos archivos jar externos y los hemos incluido en la carpeta JAVA_HOME/lib/ext. Esto nos ha funcionado por años, pero recientemente un nuevo programador se unió a nuestro equipo y parece enfático en que esta es una de las cosas malas que hay que hacer. No puedo entender por qué y estoy tratando de investigar un poco antes de seguir profundizando con este desarrollador. ¿Hay algo que me falta aquí?

Answer 1

Sí - es una mala cosa. Piénselo: la aplicación depende del JRE y algunos frascos adicionales. ¿Qué pasa si actualiza el JRE? Luego debe recordar copiar los archivos en el nuevo JRE. ¿Qué sucede si necesita configurar la aplicación en un sistema nuevo? Tienes que copiar la aplicación allí, y luego también recuerdas copiar los archivos jar externos en el JRE en ese sistema.

Ambos problemas no serían un problema en absoluto si solo empaqueta la aplicación correctamente junto con los contenedores externos que necesita. Si no ves esto, entonces tal vez no sea un problema en absoluto. Pero aún deberías estar agradecido por el chico nuevo por compartir su opinión.

Answer 2

Además de la respuesta de weiji (empaque y actualizaciones de las nuevas versiones de JVM), existen otros riesgos.

Si está utilizando el administrador de seguridad en cualquiera de sus aplicaciones, las bibliotecas en ext a menudo tienen mucha más capacidad de forma predeterminada: se tratan de manera similar a las bibliotecas del sistema. Debe asegurarse de que puede confiar, en el sentido de hacer cumplir las reglas de seguridad, estas clases. ¿Los autores pensaron a través de lo que estaban exponiendo correctamente? Si estas clases no usan control de acceso para cambiar el contexto de seguridad, entonces no necesita preocuparse por esto, pero ¿sabe si lo hacen o no? (Por ejemplo, un método que proporciona acceso a un archivo y usa AccessController, ¿se asegura? que la persona que llama tiene los permisos de archivo correctos?)

¿Pueden todas sus aplicaciones usar la misma versión exacta de la biblioteca? ¿Qué sucede cuando necesita actualizar esa biblioteca (no solo la JVM)? ¿Romperás alguna de tus aplicaciones? Deberás volver a probar todo. Las bibliotecas en ext son cargadas por el cargador de clases de extensión que, debido a la delegación principal, tiene mayor precedencia que el cargador normal (es decir, CLASSPATH) por lo que su aplicación garantiza su uso y no hay forma de que una aplicación individual para anular la biblioteca en ext con una versión diferente.

Si desea compartir las bibliotecas en sus aplicaciones, ¿por qué no proporcionar una carpeta separada de bibliotecas comunes que las aplicaciones pueden configurarse individualmente (CLASSPATH) como referencia? Luego, si tiene problemas con una aplicación y una biblioteca, puede cambiar a una versión diferente de las bibliotecas o solo para esa, colocarla antes en CLASSPATH (si eso funciona, debe probar esto también, ya que puede haber otra dependencia). cuestiones). Esto le permitirá tener más control individual para cada aplicación. Pero entonces, agrupar todas las bibliotecas requeridas con su aplicación es lo más seguro ya que puede volver a probar e implementar actualizaciones de biblioteca para aplicaciones individuales.

Answer 3

También parece que JEP-220 está aparentemente desaprobando este comportamiento con algunos medios arbitrarios para "posiblemente reemplazarlo" con algún otro comportamiento.