Controllo utilizzo codice Java

Question

Sto lavorando su una biblioteca in cui vogliamo determinare quanta parte della nostra biblioteca viene utilizzata.CIOÈ.vogliamo sapere quanti metodi nella nostra libreria sono pubblici, ma non vengono mai chiamati.

Obiettivo:L'analisi statica determina quante righe di codice chiamano ciascun metodo pubblico nel pacchetto A nel progetto corrente.Se il numero di chiamate è zero, il metodo deve essere segnalato come tale.

Answer 1

Credo che tu stia cercando questo plugin per Eclipse --> Rilevatore UC

Dalla documentazione (avviso di pagamento al secondo punto elenco)

• Codice non necessario (morto).
• Codice in cui la visibilità potrebbe essere modificata in protezione, predefinita o privata
• Metodi dei campi, che possono essere definitivi

Su scala più ampia, se vuoi eseguire l'analisi statica a livello di oggetto, guarda questo strumento di IBM -->Analisi strutturale per Java.È davvero utile per l'analisi degli oggetti di librerie, API, ecc.

Answer 2

Non è esattamente quello che stai cercando, ma:

Qualcosa di simile può fare con gli strumenti di copertura del codice (come Cobertura ). Non fanno l'ispezione statica del codice sorgente, ma strumento il bytecode per raccogliere metriche in fase di esecuzione. Naturalmente, è necessario guidare l'applicazione in modo che esercita tutte le modalità di utilizzo, e potrebbe perdere i percorsi di codice più rari.

Sul fronte analisi statica, forse questi strumenti possono aiutare (il progetto Apache li utilizza per verificare la compatibilità API per le nuove uscite, sembra che il compito è in qualche modo correlata a quello che si sta tentando di fare):

• Clirr è uno strumento che controlla librerie Java per binaria e sorgente di compatibilità con le versioni precedenti. In pratica si dà due set di file JAR e Clirr discariche fuori un elenco dei cambiamenti nel API pubblica.
• JDiff è un doclet Javadoc che genera un report HTML di tutti i pacchetti, le classi, costruttori, metodi , ei campi che sono stati rimossi, aggiunti o modificati in alcun modo, tra cui la loro documentazione, quando due API vengono confrontati.

Answer 3

l'uso del client di chiamate riflettenti è un foro in analisi statica di prendere in considerazione. Poiché non c'è modo di sapere con certezza che un particolare metodo non viene chiamato tramite qualche schema riflessione bizzarra. Quindi, forse una combinazione di runtime e l'analisi statica potrebbe essere migliore.

Answer 4

Non credo che si è in grado di misurare quanto "spesso" una classe o è necessaria una funzione.
Ci sono alcune semplici domande:

• Ciò che definisce, se una statistica utilizzo della vostra biblioteca gioco è "normale" o un "outlier"? È sbagliato uccidere se stessi nel gioco troppo spesso? Si potrebbe utilizzare la classe "killScreen" più spesso come un buon giocatore.
• Ciò che definisce "molto"? Ora o utilizzo contano? POJO si consumano tempo rara, ma sono utilizzati abbastanza frequentemente.

Conclusione:
Non so che cosa si sta cercando di realizzare.
Se si desidera visualizzare le dipendenze di codice, ci sono altri strumenti per fare questo . Se stai cercando di misurare la vostra esecuzione di codice, ci sono profiler o parametri di riferimento per Java. Se sei un geek statistica, sarai felice con RapidMiner ;)

Buona fortuna con quello!

Answer 5

Vorrei suggerire JDepend mostra le dipendenze tra i pacchetti e le classi, eccellente per trovare le dipendenze cicliche! http://clarkware.com/software/JDepend.html (Ha un plugin Eclipse: http://andrei.gmxhome.de/jdepend4eclipse/

e anche PMD per altre metriche http://pmd.sourceforge.net/

Answer 6

IntelliJ ha uno strumento per rilevare i metodi, campi, di classe che può avere i modificatori più ristretti. E 'anche una ha una soluzione rapida per applicare questi cambiamenti che si possono risparmiare un sacco di lavoro pure. Se non si vuole pagare per questo, è possibile ottenere la licenza eval di 30 giorni, che è un tempo più che sufficiente per modificare il codice, non è qualcosa che il tuo dovrebbe bisogno di fare molto spesso.

A proposito:. IntelliJ ha circa 650 controlli di codice per migliorare la qualità del codice, circa la metà ha correzioni automatiche quindi suggerisco passare un paio di giorni di utilizzarlo per il refactoring / riordinare il codice

Answer 7

Si prega di dare un'occhiata alla Morto Codice Detector . Essa sostiene di fare proprio quello che state cercando:. Trovando codice inutilizzato utilizzando l'analisi statica

Answer 8

Ecco sono alcune liste di Java strumenti di copertura del codice. Non ho usato uno di questi personalmente, ma potrebbe iniziare:

• http://java-source.net/open-source/code-coverage
• http: //www.codecoveragetools .com / index.php / copertura-processo / code-copertura-tools-java.html

Answer 9

Proguard può essere un'opzione troppo ( http://proguard.sourceforge.net/ ):

"Alcuni usi di ProGuard sono:

• ...
• Listato codice morto, in modo che possa essere rimosso dal codice sorgente.
• ... "

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

Answer 10

Si potrebbe scrivere la propria utilità per questo (entro un ora dopo aver letto questo) utilizzando la libreria di analisi ASM bytecode ( http: //asm.ow2.org ). Avrai bisogno di implementare un ClassVisitor e MethodVisitor. Potrai utilizzare un ClassReader per analizzare i file di classe nella libreria.

• visitMethod del tuo ClassVisitor (..) verrà chiamato per ogni metodo dichiarato.
• visitMethodInsn del tuo MethodVisitor (..) verrà chiamato per ogni metodo chiamato.

Mantenere una mappa per fare il conteggio. I tasti rappresentano i metodi (vedi sotto). Ecco po 'di codice:

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

In sostanza il gioco è fatto. Vi trovate ad iniziare lo spettacolo con qualcosa di simile:

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

Enjoy!