Código de Java Uso del inspector

StackOverflow https://stackoverflow.com/questions/766493

Pregunta

Estoy trabajando en una biblioteca donde queremos determinar qué parte de nuestra biblioteca se está utilizando. ES DECIR. queremos saber cuántos métodos en nuestra biblioteca son públicos, pero nunca siendo llamados.

Objetivo: Análisis estático Determinar el número de líneas de código de llamada cada método público en el paquete A en el proyecto actual. Si el número de llamadas es cero, el método debe ser reportado como tal.

¿Fue útil?

Solución

Me creer que busca este plugin Eclipse -> UCDetector

A partir de la documentación (aviso de pago al segundo punto)

  • innecesario (muerto) código
  • Código, donde la visibilidad podría ser cambiado para proteger, por defecto o privada
  • Los métodos de campos, que puede ser final

En la escala más grande, si usted quiere hacer objeto de análisis estático de nivel, mira esta herramienta de IBM -> Análisis estructural para Java . Es muy útil para el análisis objetivo de las bibliotecas, API, etc.

Otros consejos

No es exactamente lo que está buscando, pero:

Algo similar puede hacer con las herramientas de cobertura de código (como Cobertura ). Ellos no hacen la inspección estática del código fuente, pero el código de bytes de instrumentos para recopilar métricas en tiempo de ejecución. Por supuesto, es necesario impulsar la aplicación de una manera que ejerce todo el patrón de uso, y podría perderse las rutas de código raras.

En el frente análisis estático, tal vez estas herramientas pueden ayudar a que (el proyecto Apache los utiliza para comprobar la compatibilidad de la API para los nuevos lanzamientos, parece que esa tarea es algo relacionado con lo que está tratando de hacer):

  • Clirr es una herramienta que comprueba las bibliotecas de Java para la compatibilidad binaria y la fuente con versiones anteriores. Básicamente le dan dos conjuntos de archivos jar y Clirr vuelca una lista de los cambios en la API pública.
  • JDiff es un doclet Javadoc que genera un informe HTML de todos los paquetes, clases, constructores, métodos , y los campos que se han eliminado, añadido o modificado en cualquier forma, incluyendo su documentación, cuando se comparan dos APIs.

El uso de cliente de llamadas de reflexión es un agujero en el análisis estático a considerar. Como no hay manera de saber con certeza que un método en particular no se está llamando a través de algún esquema de reflexión extraña. Por lo tanto, tal vez una combinación de tiempo de ejecución y el análisis estático podría ser mejor.

No creo que usted es capaz de medir la "frecuencia" de una clase o se necesita una función.
Hay algunas preguntas simples:

  • ¿Qué define, si una estadística de uso de la biblioteca de juego es "normal" o un "atípico"? ¿Está mal matar a ti mismo en el juego con demasiada frecuencia? Se podría utilizar la clase "killScreen" con mayor frecuencia como un buen jugador.
  • ¿Qué define "mucho"? Tiempo o uso cuentan? POJOs consumirán tiempo raro, pero se utiliza con bastante frecuencia.

Conclusión:
No sé lo que está tratando de lograr.
Si desea mostrar sus dependencias de código, hay otras herramientas para hacer esto . Si usted está tratando de medir su ejecución de código, hay o puntos de referencia para Java. Si usted es un friki estadística, que estará perfectamente RapidMiner ;)

Buena suerte con eso!

Yo sugeriría JDepend muestra las dependencias entre los paquetes y las clases, excelente para encontrar dependencias cíclicas! http://clarkware.com/software/JDepend.html (Tiene un plugin de Eclipse: http://andrei.gmxhome.de/jdepend4eclipse/

y también PMD para otras métricas http://pmd.sourceforge.net/

IntelliJ tiene una herramienta para detectar los métodos, campos, clase que puede tener modificadores más restringidos. También tiene un una solución rápida para aplicar estos cambios, que le puede ahorrar una gran cantidad de trabajo también. Si usted no quiere pagar por ello, se puede obtener la licencia de eval 30 días, que es más que suficiente tiempo para cambiar su código, no es algo que su debe necesitar para hacer muy a menudo.

Por cierto:. IntelliJ tiene cerca de 650 inspecciones de código para mejorar la calidad del código, alrededor de la mitad tiene correcciones automáticas por lo que sugiero pasar un par de días de usarlo para refactorizar / buena visibilidad en el código

Por favor, eche un vistazo a Detector Muerto Código . Que pretende hacer justo lo que busca:. Búsqueda de código no utilizado en el análisis estático

Aquí están algunas de las listas de Java herramientas de cobertura de código. No he utilizado ninguno de estos personalmente, pero podría empezar:

Proguard puede ser una opción también ( http://proguard.sourceforge.net/ ):

"Algunos usos de ProGuard son:

  • ...
  • listado de código muerto, por lo que puede ser eliminado del código fuente.
  • ... "

http://proguard.sourceforge.net/manual/examples.html #deadcode

Se puede escribir su propia utilidad para que (dentro de una hora después de leer esto) utilizando la biblioteca de análisis de código de bytes ASM ( http: //asm.ow2.org ). Tendrá que poner en práctica un ClassVisitor y una MethodVisitor. Vamos a usar un ClassReader para analizar los archivos de clase en su biblioteca.

  • visitMethod de su ClassVisitor (..) se llama para cada método declarado.
  • visitMethodInsn de su MethodVisitor (..) se llama para cada método llamado.

Mantener un mapa para hacer el recuento. Las teclas representan los métodos (véase más adelante). Aquí hay algo de código: 

class MyClassVisitor {
    // ...
    public void visit(int version, int access, String name, ...) {
        this.className = name;
    }
    public MethodVisitor visitMethod(int access, String name, String desc, ...):
        String key = className + "." + name + "#" + desc;
        if (!map.containsKey() {
            map.put(key, 0);
        }
        return new MyMethodVisitor(map);
    }
    // ...
}

void class MyMethodVisitor {
    // ...
    public visitMethodInsn(int opcode, String name, String owner, String desc, ...) {
        String key = owner + "." + name + "#" + desc;
        if (!map.containsKey() {
            map.put(key, 0);
        }
        map.put(key, map.get(key) + 1);
    }
    // ...
}

Básicamente eso es todo. Tu eres de iniciar la presentación con algo como esto: 

Map<String,Integer> map = new HashMap<String,Integer>();
for (File classFile : my library) {
    InputStream input = new FileInputStream(classFile);
    new ClassReader(input).accept(new MyClassVisitor(map), 0);
    input.close();
}
for (Map.Entry<String,Integer> entry : map.entrySet()) {
    if (entry.getValue() == 0) {
        System.out.println("Unused method: " + entry.getKey());
    }
}

Disfrute!

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top