Cómo determinar qué JAR se utilizan en una aplicación

Question

Una aplicación existente tiene una tonelada de archivos JAR en su classpath. Alguien debe haber agregado todos los JAR inicialmente solo para estar seguro. Algunos de los JAR obviamente no se estaban utilizando y ya hemos eliminado algunos de estos JAR innecesarios sin causar ningún problema.

¿Cómo se determina qué JAR se están utilizando y cuáles no se necesitan (además del método de prueba y error)?

Answer 1

Tattletale es una gran herramienta para esto. Funciona en el bytecode, por lo que es posible que algunas clases se utilicen mediante reflexión y no aparezcan en el informe.

Here (enlace ya no funciona) es un informe de ejemplo. Como puede ver, solo tiene la función que está buscando "JAR no utilizado".

Answer 2

Tenga en cuenta que la prueba y el error pueden ser un problema, especialmente si la aplicación carga clases dinámicamente (por ejemplo, Class.forName) ya que eliminar un JAR no impide que la aplicación se inicie y (aparentemente) funciona bien, pero puede fallar más tarde si no se encuentran las clases objetivo.

Además, hay muchas herramientas que pueden usarse para analizar una aplicación Java y descubrir dependencias (he usado Dependency Finder, aunque no exactamente para este propósito), sin embargo, tenga en cuenta que la mayoría de ellas tampoco encontrarán clases que se cargan dinámicamente como se describió anteriormente.

Answer 3

Si alguno de ellos se carga dinámicamente, es posible que las herramientas automáticas los pierdan. Restablecía los tiempos de acceso en los archivos, ejecutaba la aplicación durante un tiempo (y me aseguraba de invocar la mayor funcionalidad posible) y veía a qué archivos se accedía y cuáles no. Es posible que deba repetir esto en cada plataforma en la que su aplicación necesite ejecutarse, por si acaso.

Answer 4

Utilicé la siguiente secuencia de comandos de shell en un proyecto de portal jboss para obtener la lista de archivos jar que se usan en las instrucciones de importación. Esto solo funcionará para las dependencias directas, no para la carga dinámica o incluso cuando se utilizó el nombre de clase completo en la fuente. Además, el contenedor proporciona todos los archivos jar y sus dependencias transitivas, por lo que solo son necesarios para compilar el código.

El objetivo era crear un maven pom para el proyecto y encontrar los archivos que necesitaban implementarse en nuestro administrador de repositorios nexus. Puede ser útil como punto de partida para listar los archivos que son definitivamente necesarios, los archivos jar restantes deberían verificarse de otras maneras. Si el jar también está disponible en un repositorio de maven, puede ver sus dependencias, por ejemplo.

#!/bin/sh 
JBOSS_HOME=/path/to/jboss/installation 
JBOSS_LIB=$JBOSS_HOME/server/default/lib 
JBOSS_DEPLOY=$JBOSS_HOME/server/default/deploy 
SRC_DIR=src 

for f in $JBOSS_LIB/*.jar $JBOSS_DEPLOY/jboss-portal.sar/lib/*.jar $JBOSS_DEPLOY/jboss-portal.sar/portal-cms.sar/lib/*.jar $JBOSS_DEPLOY/ejb3.deployer/*.jar 
do 
    for c in `jar -tf $f | tr '/$' '..'` 
    do 
     #echo "^import ${c%.class};" 
     if `grep "^import ${c%.class};" -h -r $SRC_DIR -q` 
     then 
      echo $f $c 
     fi 
    done 
done