Du code Java Utilisez Checker

Question

Je travaille sur une bibliothèque où nous voulons déterminer la quantité de notre bibliothèque est utilisée. C'EST À DIRE. nous voulons savoir combien de méthodes dans notre bibliothèque sont publiques, mais jamais appelé.

Objectif: Analyse statique Déterminer le nombre de lignes de code appel à chaque méthode publique dans le package A dans le projet en cours. Si le nombre d'appels est égal à zéro, la méthode doit être signalé comme tel.

Answer 1

Je crois que vous êtes à la recherche de ce plugin Eclipse -> UCDetector

De la documentation (avis de rémunération au deuxième point)

• Code non nécessaire (morts)
• code où pourrait être changé la visibilité à la protection, par défaut ou privé
• Méthodes de champs, qui peuvent être finale

à plus grande échelle, si vous voulez faire l'objet Niveau d'analyse statique, regardez cet outil d'IBM -> Analyse structurale pour Java . Il est très utile pour l'analyse d'objets des bibliothèques, des API, etc.

Answer 2

Pas exactement ce que vous cherchez, mais:

Quelque chose de similaire se fait avec des outils de couverture de code (comme Cobertura ). Ils ne font pas l'inspection statique du code source, mais le bytecode instrument pour recueillir des paramètres lors de l'exécution. Bien sûr, vous devez conduire l'application d'une manière qui exerce toutes les habitudes d'utilisation, et peut-être manquer les chemins de code plus rares.

Sur le plan de l'analyse statique, peut-être ces outils peuvent vous aider (le projet Apache les utilise pour vérifier la compatibilité de l'API pour les nouvelles versions, semble cette tâche est un peu lié à ce que vous essayez de faire):

• Clirr est un outil qui vérifie les bibliothèques Java pour la compatibilité binaire et la source avec les anciennes versions. Fondamentalement, vous donnez deux ensembles de fichiers jar et Clirr dumps une liste des changements dans le api public.
• JDiff est un doclet Javadoc qui génère un rapport HTML de tous les packages, classes, constructeurs, méthodes et les champs qui ont été supprimés, ajoutés ou modifiés de quelque façon, y compris leur documentation, quand on compare les deux API.

Answer 3

Utilisation du client d'appels de réflexion est un trou dans l'analyse statique à considérer. Comme il n'y a aucun moyen de savoir avec certitude qu'une méthode particulière n'est pas appelé via un système de réflexion bizarre. Alors, peut-être une combinaison d'exécution et l'analyse statique pourrait être mieux.

Answer 4

Je ne pense pas que vous êtes en mesure de mesurer la « souvent » une classe ou une fonction est nécessaire.
Il y a quelques questions simples:

• Ce qui définit, si une statistique d'utilisation de votre bibliothèque de jeu est « normal » ou un « aberrant »? Est-il tort de vous tuer dans le jeu trop souvent? Vous utiliserez la classe « killScreen » plus souvent comme un bon joueur.
• Ce qui définit "beaucoup"? compter le temps ou l'utilisation? POJO consommera du temps rare, mais sont utilisés assez souvent.

Conclusion:
Je ne sais pas ce que vous essayez d'accomplir.
Si vous souhaitez afficher vos dépendances de code, il existe d'autres outils pour ce faire . Si vous essayez de mesurer l'exécution de votre code, il y a profileur ou points de repère pour Java. Si vous êtes un geek statistique, vous serez heureux avec RapidMiner ;)

Bonne chance!

Answer 5

Je suggère JDepend vous montre les dépendances entre les packages et les classes, excellente pour trouver des dépendances cycliques! http://clarkware.com/software/JDepend.html (Il a un plugin Eclipse: http://andrei.gmxhome.de/jdepend4eclipse/

et aussi PMD pour d'autres mesures http://pmd.sourceforge.net/

Answer 6

IntelliJ dispose d'un outil pour détecter les méthodes, les champs, la classe qui peut avoir des modificateurs plus restreints. Il a également un a une solution rapide pour appliquer ces modifications qui peuvent vous faire économiser beaucoup de travail aussi bien. Si vous ne voulez pas payer pour cela, vous pouvez obtenir la licence de eval 30 jours qui est plus que suffisant pour changer votre code, ce ne est pas quelque chose que votre devrait avoir besoin de faire très souvent.

BTW. IntelliJ a environ 650 inspections de code pour améliorer la qualité du code, environ la moitié a des corrections automatiques, donc je suggère de passer quelques jours de l'utiliser pour factoriser / ranger votre code

Answer 7

S'il vous plaît jeter un oeil à Mort code détecteur . Il prétend faire exactement ce que vous cherchez. Trouver un code non utilisé en utilisant l'analyse statique

Answer 8

Voici quelques listes d'outils de couverture de code Java. Je ne l'ai pas utilisé l'un de ces personnellement, mais il pourrait vous aider à démarrer:

• http://java-source.net/open-source/code-coverage
• http: //www.codecoveragetools .com / index.php / couverture processus / couverture de code-tools-java.html

Answer 9

Proguard peut être une option trop ( http://proguard.sourceforge.net/ ):

"Certaines utilisations de ProGuard sont:

• ...
• Liste de code mort, il peut donc être retiré du code source.
• ... «

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

Answer 10

Vous pouvez écrire votre propre utilitaire pour cela (moins d'une heure après avoir lu ce) en utilisant la bibliothèque d'analyse ASM bytecode ( http: //asm.ow2.org ). Vous aurez besoin de mettre en œuvre un ClassVisitor et un MethodVisitor. Vous utiliserez un ClassReader pour analyser les fichiers de classe dans votre bibliothèque.

• visitMethod de votre ClassVisitor (..) sera appelée pour chaque méthode déclarée.
• visitMethodInsn de votre MethodVisitor (..) sera appelée pour chaque méthode appelée.

Maintenir une carte pour effectuer le comptage. Les touches représentent les méthodes (voir ci-dessous). Voici un code:

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);
    }
    // ...
}

En fait c'est tout. Vous êtes en train de commencer le spectacle avec quelque chose comme ceci:

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());
    }
}

Amusez-vous!