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 se los llama.Java Code Use Checker
Objetivo: Análisis estático Determinar cuántas líneas de código llaman a 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 informarse como tal.
I belive que busca este plugin Eclipse ->UCDetector
De la documentación (Aviso de pago al segundo punto)
a mayor escala, si usted quiere hacer objeto de análisis estático de nivel, mira en esta herramienta de IBM ->Structural Analysis for Java. Es realmente útil para el análisis de objetos de bibliotecas, API, etc.
Aquí hay algunas listas de herramientas de cobertura de código Java. No he utilizado ninguno de estos personalmente, pero podría empezar:
El problema con las herramientas de cobertura de código es que funcionan en tiempo de ejecución, por lo que es posible que pierda rutas de código "raras". – Thilo
No es exactamente lo que están buscando, pero:
Algo similar hacerse con herramientas de cobertura de código (como Cobertura). No hacen una inspección estática del código fuente, sino que instrumentan el bytecode para recopilar métricas en el tiempo de ejecución. Por supuesto, debe conducir la aplicación de una manera que ejerza todos los patrones de uso, y podría pasar por alto las rutas de código más 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):
No creo que pueda medir cómo "a menudo" se necesita una clase o una función.
Hay algunas preguntas simples:
Conclusión:
no sé lo que está tratando de lograr.
Si desea mostrar sus dependencias de código, existen otras tools para hacerlo. Si está intentando medir la ejecución de su código, hay profiler or benchmarks para Java. Si eres un fanático de las estadísticas, estarás contento con RapidMiner;)
¡Buena suerte con eso!
Sugeriría que JDepend le muestre las dependencias entre paquetes y clases, ¡excelente para encontrar dependencias cíclicas! http://clarkware.com/software/JDepend.html (que tiene un plugin de Eclipse: http://andrei.gmxhome.de/jdepend4eclipse/
y también PMD para otras métricas http://pmd.sourceforge.net/
El uso del cliente de llamadas reflexivas es un agujero en el análisis estático a considerar. Como no hay manera de saber con certeza si un método particular no se está llamando a través de algún esquema de reflexión extraño. Entonces, tal vez una combinación de tiempo de ejecución y análisis estático sea lo mejor.
Proguard puede ser una opción demasiado (http://proguard.sourceforge.net/):
"Algunos usos de ProGuard son:
Ver también http://proguard.sourceforge.net/manual/examples.html#deadcode
Usted 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 implementar un ClassVisitor y un MethodVisitor. Utilizará un ClassReader para analizar los archivos de clase en su biblioteca.
Mantenga un Mapa para hacer el recuento. Las teclas representan los métodos (ver abajo). Aquí hay un 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. Estás comenzando el programa 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());
}
}
¡Disfrútalo!
Si el método A llama al método B, el método B se marcará como "usado", incluso si no se utiliza el método A, por lo que esta no es la forma correcta de contar. Debe realizar un cierre transitivo en "usado". –
IntelliJ tiene una herramienta para detectar métodos, campos, clases que pueden tener modificadores más restringidos.También tiene una solución rápida para aplicar estos cambios que también puede ahorrarle mucho trabajo. Si no quiere pagar, puede obtener la licencia de evaluación de 30 días, que es tiempo más que suficiente para cambiar su código, no es algo que deba hacer muy a menudo.
BTW: IntelliJ tiene alrededor de 650 inspecciones de código para mejorar la calidad del código, aproximadamente la mitad tiene correcciones automáticas, por lo que sugiero pasar un par de días usándolo para refactorizar/ordenar su código.
Por favor, eche un vistazo a Dead Code Detector. Afirma hacer justo lo que está buscando: encontrar el código no utilizado usando análisis estático.
¿Parece que quieres algo como Cobertura o Emma que supervisa tu aplicación en ejecución, en lugar de depender de un conjunto de cobertura de prueba unitaria? –